inspire infrastructure for spatial information in europe ... · interoperability of spatial data...

INSPIRE Infrastructure for Spatial Information in Europe

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

Title D2.8.III.2 INSPIRE Data Specification on Buildings – Draft Guidelines

Creator INSPIRE Thematic Working Group Buildings

Date 2012-07-09

Subject INSPIRE Data Specification for the spatial data theme Buildings

Publisher INSPIRE Thematic Working Group Buildings

Type Text

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

Contributor Members of the INSPIRE Thematic Working Group Buildings

Format Portable Document Format (pdf)

Source

Rights Public

Identifier D2.8.III.2_v3.0RC22

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)

Coverage Project duration

INSPIRE Reference: D2.8.III._v3.0RC1

TWG-BU Data Specification on Buildning 2012-04-20 Page II

Change Log Version Changed

Sections Changes made

2.9 2.2 Due to lack of consensus to extend scope of theme BU, review of scope of theme Buildings. Profile approach and Links/overlaps with other themes reviewed

2.9 5.2 Content: due to lack of consensus to extend scope of theme BU, OtherConstruction removed from core profile => AbstractConstruction removed Formalism: 2 abstract feature types, one for semantics (common with core2D) and one for geometric representation

2.9 5.3 5.3 dedicated to core3D (instead of extended 2D) Content: due to lack of consensus to extend scope of theme BU, OtherConstruction removed from core profile => AbstractConstruction removed Formalism: 2 abstract feature types, one for semantics (common with core2D) and one for geometric representation Comments taken into account: Representation of 3D geometry by GM_MultiSurface allowed. Representation of additional 2D geometry allowed Metadata attributes on 3Dgeometry added.

2.9 5.4 5.3 dedicated to extended 2D (instead of core 3D) Content: new user requirements (check-lists + comments) taken into account - feature type Installation added - attributes added on Building and BuildingUnit : address, heatingSource, heatingSystem, connection ToGas/Electricity/Sewage/Water, FloorDescription - attribute openGroundFloor removed from Building - attributes address, energyPerformance, use, officialarea, officialValue added to BuildingUnit - data types about officialArea and officialValue refined Formalism: new abstract feature types to show better similarities and differences between extended 2D and extended 3D

2.9 5.6 Content: new user requirements (check-lists + comments+ evolutions of CityGML) taken into account - feature types InternalBuildingInstallation, OuterFloorSurface, OuterCeilingSurface , Rooms and BuildingUnit added => inclusion of LoD4 of City GML and of updates of CityGML - full content of extended2D included Formalism: new abstract feature types to show better similarities and differences between extended 2D and extended 3D

2.9 7 Recommendations about minimum quality requirement added => better consistency between semantic LoD and scale/accuracy of data

2.9 8 Recommendations about Lineage Updated paragraph about theme specific metadata / template for additional information

2.9 10 Updated clause (scope, use of elevationCRS reference, temporal aspects, extension of code lists, …)


TWG-BU Data Specification on Buildning 2012-04-20 Page III

2.9 11 Update of portrayal clause: - style for OtherConstruction deleted - portrayal for core 3D data added

2.9 Annex C Update of annex C to take into account: - evolution of CityGML - evolution of INSPIRE 3D profiles

2.9 Annex E Update (new check-lists) 2.9 Annex F New annex to present potential alternative modelling approach for v3 of DS

BU 3.0 executive

summary Update and reformulation of executive summary

3.0 2.2 Notion of modular scope added to give different priorities to buildings and constructions according their size and nature.

3.0 5.2 Code list about building nature reviewed. 3.0 5.3 In order to ensure that extended profiles contain same content as core profile

+ additionnal content, core 3D profile allows the 4 LoD of City GML. 3.0 5.4 Attribute FloorDistribution added

Code list about installation and other construction nature reviewed. Official Area reference value split into 2 code lists, one for CLGE, one (empty) for other standards

3.0 5.5 Changes in the geometric representations of feature types. Feature Catalogue completed.

3.0 6 Recommendations made more explicit 3.0 7 Usability for 2 use cases (computation of population and vulnerability to

eathquake) added ISO 19157 used instead of ISO19115 for quality measures.

3.0 8 MD_ContentInformation added. 3.0 9 Reformulation of requirements regarding encoding 3.0 10 Updated clause, mainly about interpretation of scope and Building /

BuildingPart 3.0 11 Correction of portrayal ; no portrayal for 3D 3.0 annexes

B,C, D Update of annexes

3.0 annex F Annnex F deleted 3.0 rc2 5 Application schema Base added to collect the common elements to all other

application schemas. Restructuration of data type related to 3D geometry.


TWG-BU Data Specification on Buildning 2012-04-20 Page IV

Foreword How to read the document? This document describes the “INSPIRE data specification on Buildings – Guidelines” version 3.0RC2 as developed by the Thematic Working Group (TWG) TWG-BU using both natural and a conceptual schema language. The data specification is based on a common template used for all data specifications and has been harmonised using the experience from the development of the Annex I 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. This document includes two executive summaries that 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/will be responsible for implementing INSPIRE within the field of Buildings. 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.


TWG-BU Data Specification on Buildning 2012-04-20 Page V

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 will be 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 are being specified: metadata, interoperability of spatial data themes (as described in Annexes I, II, III of the Directive) and spatial data services, network services and technologies, data and service sharing, and monitoring and reporting procedures. INSPIRE does not require collection of new data. However, after the period specified in the Directive1 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 within 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)2, have provided reference materials, participated in the user requirement and technical3 surveys, proposed experts for the Data Specification Drafting Team4 and Thematic Working Groups5 and participated in the public stakeholder

1 For all 34 Annex I,II and III data themes: within two years of the adoption of the corresponding Implementing Rules for newly collected and extensively restructured data and within 5 years for other data in electronic format still in use 2 The current status of registered SDICs/LMOs is available via INSPIRE website: http://inspire.jrc.ec.europa.eu/index.cfm/pageid/42 3 Surveys on unique identifiers and usage of the elements of the spatial and temporal schema, 4 The Data Specification Drafting Team has been composed of experts from Austria, Belgium, Czech Republic, France, Germany, Greece, Italy, Netherlands, Norway, Poland, Switzerland, UK, and the European Environmental Agency 5 The Thematic Working Groups of Annex II and III themes have been composed of experts from Austria, Belgium, Bulgaria, Czech Republic, Denmark, Finland, France, Germany, Hungary, Ireland, Italy, Latvia, Netherlands, Norway, Poland, Romania, Slovakia, Spain, Sweden, Switzerland, Turkey, UK, the European Commission, and the European Environmental Agency


TWG-BU Data Specification on Buildning 2012-04-20 Page VI

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 specifications6. This open and participatory approach was successfully used during the development of the data specification on Annex I data themes as well as during the preparation of the Implementing Rule on Interoperability of Spatial Data Sets and Services7 for Annex I spatial data themes., 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 data specifications and provides a coherent set of requirements and recommendations to achieve interoperability. The pillars of the framework are five technical documents:

• The Definition of Annex Themes and Scope8 describes in greater detail the spatial data themes defined in the Directive, and thus provides a sound starting point for the thematic aspects of the data specification development.

• The Generic Conceptual Model9 defines the elements necessary for interoperability and

data harmonisation including cross-theme issues. It specifies requirements and recommendations with regard to data specification elements of common use, like the spatial and temporal schema, unique identifier management, object referencing, a generic network model, some common code lists, etc. Those requirements of the Generic Conceptual Model that are directly implementable will be included in the Implementing Rule on Interoperability of Spatial Data Sets and Services.

• The Methodology for the Development of Data Specifications10 defines a repeatable

methodology. It describes how to arrive from user requirements to a data specification through a number of steps including use-case development, initial specification development and analysis of analogies and gaps for further specification refinement.

• The “Guidelines for the Encoding of Spatial Data”11 defines how geographic information

can be encoded to enable transfer processes between the systems of the data providers in the Member States. Even though it does not specify a mandatory encoding rule it sets GML (ISO 19136) as the default encoding for INSPIRE.

• The “Guidelines for the use of Observations & Measurements and Sensor Web

Enablement-related standards in INSPIRE Annex II and III data specification development” provides guidelines on how the “Observations and Measurements” standard (ISO 19156) is to be used within INSPIRE.

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 language12. 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

6 For Annex II+III, the consultation phase lasted from 20 June to 21 October 2011. 7 Commission Regulation (EU) No 1089/2010 implementing Directive 2007/2/EC of the European Parliament and of the Council as regards interoperability of spatial data sets and services, published in the Official Journal of the European Union on 8th of December 2010. 8 http://inspire.jrc.ec.europa.eu/reports/ImplementingRules/DataSpecifications/D2.3_Definition_of_Annex_Themes_and_scope_v3.0.pdf 9 http://inspire.jrc.ec.europa.eu/reports/ImplementingRules/DataSpecifications/D2.5_v3.3.pdf 10

http://inspire.jrc.ec.europa.eu/reports/ImplementingRules/DataSpecifications/D2.6_v3.0.pdf 11 http://inspire.jrc.ec.europa.eu/reports/ImplementingRules/DataSpecifications/D2.7_v3.2.pdf 12 UML – Unified Modelling Language


TWG-BU Data Specification on Buildning 2012-04-20 Page VII

19100 series, the INSPIRE Generic Conceptual Model, and the application schemas13 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. Once finalised (version 3.0), the data specifications are published as technical guidelines and provide the basis for the content of the Implementing Rule on Interoperability of Spatial Data Sets and Services14. The content of the Implementing Rule is extracted from the data specifications keeping in mind short- and medium-term feasibility as well as cost-benefit considerations. The requirements included in the Implementing Rule will be 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.

13 Conceptual models related to specific areas (e.g. INSPIRE themes) 14 In the case of the Annex II+III data specifications, the extracted requirements will be used to formulate an amendment to the existing Implementing Rule.


TWG-BU Data Specification on Buildning 2012-04-20 Page VIII

Building - 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 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.


TWG-BU Data Specification on Buildning 2012-04-20 Page IX

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 Core2D profile includes various geometrical representations of buildings as 2D or 2,5D data.

• The Core3D profile has same semantic content as the core2D profile and allows in addition,

the geometric representation of buildings in any of the four levels of detail of City GML. 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, rooms, installations, boundary surfaces and textures.

• The Extended2D profile is a semantic extension of Core2D profile with additional thematic attributes (material of construction, official area or value, connection to utility networks…), classes (building units, installations) and references to other data (like cadastral data and addresses).

• The Extended3D profile is an extension of the core 3D profile for rich 3D representations at

different levels of details. It includes the possibility to represent each of the building boundaries (wall, roof …) and its associated textures. It also contains all the semantic information of extended 2D profile.

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.


TWG-BU Data Specification on Buildning 2012-04-20 Page X

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). 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 E. The Drafting Team Data Specifications included: Clemens Portele (Chair), Andreas Illert (Vice-chair), Kristine Asch, Marek Baranowski, Eric Bayers, Andre Bernath, Francis Bertrand, Markus Erhard, Stephan Gruber, Heinz Habrich, Stepan Kafka, Dominique Laurent, Arvid Lillethun, Ute Maurer-Rurack, Keith Murray, George Panopoulos, Claudia Pegoraro, Marcel Reuvers, Anne Ruas, Markus Seifert, Peter Van Oosterom, Andrew Woolf and the European Commission contact points: Steve Peedell, Katalin Tóth, Paul Smits, Vanda Nunes de Lima. The data specifications team of the Spatial Data Infrastructures Unit of the Joint Research Centre included the members who have been participating at different steps of the process: Klaudia Bielinska, Freddy Fierens, Anders Friis-Christensen, Julien Gaffuri, Darja Lihteneger, Michael Lutz, Vanda Nunes de Lima, Angel Lopez, Nicole Ostländer, Steve Peedell, Alessandro Sarretta, Jan Schulze Althoff, Paul Smits, Robert Tomas, Katalin Tóth, Martin Tuchyna. The Consolidated UML repository has been set up by Michael Lutz, Anders Friis-Christensen, and Clemens Portele. The INSPIRE Registry has been developed by Angelo Quaglia and Michael Lutz. The INSPIRE Feature Concept Dictionary and Glossary has been consolidated by Darja Lihteneger. The data specification testing has been coordinated by Martin Tuchyna. The Testing communication tools have been set up by Loizos Bailas, Karen Fullerton and Nicole Ostländer. Web communication and tools for the consultations have been developed by Karen Fullerton and Hildegard Gerlach. The stakeholders participated, as Spatial Data Interested Communities (SDIC) or Legally Mandated Organisations (LMO), in different steps of the development of the data specification development framework documents and the technical guidelines, providing information on questionnaires and user surveys, participating in the consultation process and workshops, testing the draft data specifications and supporting the work of their members in the Thematic Working Groups and Drafting Team Data Specifications. Contact information Vanda Nunes de Lima European Commission Joint Research Centre Institute for Environment and Sustainability Spatial Data Infrastructures Unit TP262, Via Fermi 2749 I-21027 Ispra (VA) ITALY E-mail: [email protected] 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/


TWG-BU Data Specification on Buildning 2012-04-20 Page XI

Table of contents

1 Scope.............................................................................................................................................. 1

2 Overview ......................................................................................................................................... 1

2.1 Name......................................................................................................................................... 1 2.2 Informal description................................................................................................................... 1

2.2.1 Context............................................................................................................................... 1 2.2.2 Decisions ........................................................................................................................... 3

2.3 Normative References .............................................................................................................. 8 2.4 Terms and definitions................................................................................................................ 9 2.5 Symbols and abbreviations..................................................................................................... 11 2.6 Notation of requirements and recommendations.................................................................... 12 2.7 Conformance........................................................................................................................... 12

3 Specification scopes ..................................................................................................................... 12

4 Identification information............................................................................................................... 12

5 Data content and structure ........................................................................................................... 13

5.1 Basic notions........................................................................................................................... 14 5.1.1 Stereotypes...................................................................................................................... 14 5.1.2 Placeholder and candidate types..................................................................................... 14 5.1.3 Voidable characteristics................................................................................................... 15 5.1.4 Enumerations................................................................................................................... 16 5.1.5 Code lists ......................................................................................................................... 16 5.1.6 Coverages........................................................................................................................ 18

5.2 Application schema <base >................................................................................................... 19 5.2.2 Feature catalogue............................................................................................................ 31

5.3 Application schema <core 2D > .............................................................................................. 48 5.3.1 Description ....................................................................................................................... 48 5.3.2 Feature catalogue............................................................................................................ 54

5.4 Application schema <core3D > ............................................................................................... 56 5.4.1 Description ....................................................................................................................... 56 5.4.2 Feature catalogue............................................................................................................ 62

5.5 Application schema <extended 2D > ...................................................................................... 68 5.5.1 Description ....................................................................................................................... 68 5.5.2 Feature catalogue............................................................................................................ 85

5.6 Application schema <extended 3D > .................................................................................... 120 5.6.1 Description ..................................................................................................................... 120 5.6.2 Feature catalogue.......................................................................................................... 128

6 Reference systems ..................................................................................................................... 160

6.1 Coordinate reference systems .............................................................................................. 160 6.1.1 Datum ............................................................................................................................ 160 6.1.2 Coordinate reference systems....................................................................................... 160 6.1.3 Display ........................................................................................................................... 161 6.1.4 Identifiers for coordinate reference systems.................................................................. 161

6.2 Temporal reference system .................................................................................................. 161 6.3 Theme-specific requirements and recommendations on reference systems ....................... 162

7 Data quality ................................................................................................................................. 163

7.1 Data quality elements............................................................................................................ 163 7.1.1 Completeness – Commission ........................................................................................ 163 7.1.2 Completeness – Omission............................................................................................. 164 7.1.3 Positional accuracy – Absolute or external accuracy .................................................... 165 7.1.4 Usability ......................................................................................................................... 166


TWG-BU Data Specification on Buildning 2012-04-20 Page XII

7.2 Minimum data quality requirements ...................................................................................... 167 7.3 Recommendation on data quality ......................................................................................... 167

8 Dataset-level metadata............................................................................................................... 169

8.1 Common metadata elements................................................................................................ 169 8.1.1 Coordinate Reference System....................................................................................... 171 8.1.2 Temporal Reference System......................................................................................... 172 8.1.3 Encoding ........................................................................................................................ 173 8.1.4 Character Encoding ....................................................................................................... 174 8.1.5 Data Quality – Logical Consistency – Topological Consistency.................................... 174

8.2 Metadata elements for reporting data quality ....................................................................... 174 8.3 Theme-specific metadata elements ...................................................................................... 176

8.3.1 Maintenance Information ............................................................................................... 176 8.3.2 <ContentInformation > ................................................................................................... 177 8.3.3 Template for additional information ............................................................................... 177

8.4 Guidelines on using metadata elements defined in Regulation 1205/2008/EC ................... 178 8.4.1 Conformity...................................................................................................................... 178 8.4.2 Lineage .......................................................................................................................... 178 8.4.3 Temporal reference ....................................................................................................... 179 8.4.4 <Lineage from MD Regulation>..................................................................................... 179

9 Delivery ....................................................................................................................................... 183

9.1 Delivery medium ................................................................................................................... 183 9.2 Encodings ............................................................................................................................. 184

9.2.1 Default Encoding(s) ....................................................................................................... 184 9.3 Error! Not a valid filename.Scope of theme Buildings .......................................................... 185

9.3.1 Purpose.......................................................................................................................... 185 9.3.2 Code lists ....................................................................................................................... 186 9.3.3 Definition of theme buildings.......................................................................................... 186

9.4 Use of Building and BuildingPart .......................................................................................... 187 9.4.1 When to split a Building into BuildingParts? .................................................................. 187 9.4.2 How to split a Building into BuildingParts? .................................................................... 189 9.4.3 How to fill the attributes of Building and BuildingPart? .................................................. 191

9.5 Mapping examples for attribute currentUse.......................................................................... 191 9.6 Temporal aspects.................................................................................................................. 192

9.6.1 Data type DateOfEvent.................................................................................................. 193 9.6.2 Demolished Buildings .................................................................................................... 193

9.7 Use of ElevationCRSReference............................................................................................ 194 9.8 Extension of code lists .......................................................................................................... 196

9.8.1 Hierarchical code list (CurentUseValue)........................................................................ 196 9.8.2 Other code lists .............................................................................................................. 196

9.9 Estimated accuracy............................................................................................................... 197

10 Portrayal...................................................................................................................................... 198

10.1 Layers to be provided by INSPIRE view services ............................................................. 198 10.1.1 Layers organisation.................................................................................................... 198

10.2 Styles to be supported by INSPIRE view services............................................................ 198 10.2.1 Styles for the layer <Building > .................................................................................. 199

Bibliography......................................................................................................................................... 204

Annex A (normative) Abstract Test Suite ........................................................................................... 206

Annex B (informative) Use cases ........................................................................................................ 207

11 Common use of building data ..................................................................................................... 207

11.1 Modelling of physical phenomena..................................................................................... 207 11.2 Computation of population in an area of interest .............................................................. 209

11.2.1 Assessment of population at night ............................................................................. 210


TWG-BU Data Specification on Buildning 2012-04-20 Page XIII

11.2.2 Assessing population at day ...................................................................................... 210 11.3 Large scale 2D mapping ................................................................................................... 212 11.4 Deriving medium scale data .............................................................................................. 213 11.5 3D models ......................................................................................................................... 216

12 Safety.......................................................................................................................................... 218

12.1 Travel security ................................................................................................................... 218 12.2 Risk assessment ............................................................................................................... 220 12.3 Risk management ............................................................................................................. 223

13 Urban expansion......................................................................................................................... 225

13.1 Integrated urban monitoring .............................................................................................. 225 13.1.1 Urban Atlas................................................................................................................. 225 13.1.2 INSPIRE Land Use .................................................................................................... 227 13.1.3 Urban metabolism ...................................................................................................... 228

13.2 Urban planning .................................................................................................................. 229 13.3 Urban monitoring ............................................................................................................... 232

14 Environment................................................................................................................................ 234

14.1 Noise ................................................................................................................................. 234 14.2 Air quality........................................................................................................................... 236 14.3 Soil..................................................................................................................................... 236 14.4 Energy / Sustainable buildings .......................................................................................... 238

14.4.1 Applying the Energy Performance of Building Directive ............................................ 239 14.4.2 Promoting reduction of CO2 emissions ...................................................................... 240 14.4.3 Sun exposure ............................................................................................................. 241

14.5 Quality of habitat................................................................................................................ 242 14.6 Buildings with historical or architectural interest ............................................................... 244

15 Infrastructures ............................................................................................................................. 246

15.1 Location of a new service/activity...................................................................................... 246 15.2 Management of service/activity ......................................................................................... 249 15.3 Management / valorisation of public patrimony................................................................. 251

16 Census........................................................................................................................................ 253

16.1 European Census.............................................................................................................. 253 16.2 Census Units ..................................................................................................................... 254

Annex C (informative) Template for additional information - Theme Buildings................................... 256

Annex F (informative) <Acknowledgements>..................................................................................... 260

16.3 As-is analysis..................................................................................................................... 260 16.4 User requirements ............................................................................................................. 261

INSPIRE Reference: D2.8.III.1_v3.0RC1

TWG-BU Data Specification on Building 2012-04-20 Page 1

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 will be published as implementation guidelines accompanying these Implementing Rules.

2 Overview

2.1 Name INSPIRE data specification for the theme Building.

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 in figure n°1. 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.



Figure n°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 can not 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:

• Glossary 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.

Safety – risk management

Urban extension Environment

Census - Statistics

Communication – Public awareness

Safety Urban expansion Environment Infrastructures

Census - Statistics

Communication – Public awareness

Natural risks (flood, fire, earthquake, landslide) Human risks (transport) Prevention / rescue management

Definition of urban areas Urbanism planning and monitoring

Pollutions (air, noise, sol) Quality of habitat Sustainable buildings (energy, …) Historical interest

Location for new infrastructure Infrastructure management Public patrimony management and valorisation

Risk / travel maps

City maps Thematic / tourism maps

3D models

Census Urban units Environmental statistics / Reporting



• Classification

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 extensible 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 modeling of Buildings: - 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 C 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 in the following figure.



Figure n°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 Building). 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 mainly basic topographic data (such as height, number of floors, classification of buildings, date of construction …) and aims to fulfil most user requirements, at least in a rough way. Core profile is based on the concepts shown in green on figure n° 2. Extended profile includes mainly data that generally comes from official/cadastral information systems. Extended profile is based on the concepts shown in pink on figure n° 2.



Extended profile does not need to be applied as a whole but 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 It is expected that most cadastral/official organism will adopt (at least partly) the feature types and attributes proposed in the extended profile, taking into account the possible restrictions/adaptations due to national regulations (e.g. privacy issues). Extended profile also includes some detailed topographic data; the main purpose is to encourage data producers to capture this information in future. Of course, it is also expected that the possibilities of extension will be used soon, but likely by very few data providers (as few data available until now). Moreover, some mechanisms (external reference, address and document) have been included to enable users to make link between the data considered as under scope of theme Building and the data considered as out of scope of the theme (such as owner/tenant, building permit, detailed activity of the building). INSPIRE data specifications will evolve in future; of course, the concepts that are now in the extended profile might be candidates for inclusion in the normative profile, during the future updates of INSPIRE specifications.

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. Profiles To summarise, the data specification includes the following set of possible profiles: Basic semantic

Rich semantic

2D geometry Core 2D profile (base + core 2D application

schemas)

Extended 2D profile (base + extended 2D application schemas)

3D geometry Core 3D profile (base + core 3D application

schemas)

Extended 3D profile (base + extended 3D application schemas)

Table n° 1: the profile approach for theme Buildings



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.

Figure n°3: the 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:

Figure n°4 : the 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.



Figure n° 5: 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.

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

Table n°2: the classification of buildings

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.

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 19123] EN ISO 19123:2007, Geographic Information – Schema for coverage geometry and

functions [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 [OGC 06-103r3] Implementation Specification for Geographic Information - Simple feature access –

Part 1: Common Architecture v1.2.0 NOTE This is an updated version of "EN ISO 19125-1:2006, Geographic information – Simple feature access – Part 1: Common architecture". A revision of the EN ISO standard has been proposed. [Regulation 1205/2008/EC] Regulation 1205/2008/EC implementing Directive 2007/2/EC of the

European Parliament and of the Council as regards metadata

2.4 Terms and definitions General terms and definitions helpful for understanding the INSPIRE data specification documents are defined in the INSPIRE Glossary15. Specifically, for the theme Building, 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

15 The INSPIRE Glossary is available from http://inspire-registry.jrc.ec.europa.eu/registers/GLOSSARY



Figure n°6: 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

Figure n°7: 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 > EXAMPLE

Figure n°8 : a building represented by 3D data (<3>) <building component > < any sub-division or element of a building> EXAMPLES: wall, roof, room



2.5 Symbols and abbreviations <AD > < Address> <AF > < Agricultural and Aquacultural Facilities> <AC > < Atmospheric Conditions > <AU > < Administrative Units > <BU > <Buildings > <CP > <Cadastral Parcels > <CRS > < Coordinate Reference System > <DS DT > < Data Specification Drafting Team > <DTM > < Digital Terrain Model > <EEA > < European Environmental Agency > <EC > < European Commission > <EL > < Elevation> <ENC > < Electronic Navigation Charts > <EPBD > < Energy Performance of Buildings Directive > <ETRS89 > < European Terrestrial Reference System 1989 <EVRS > < European Vertical Reference System > <FE > < Filter Encoding > <GCM > < Generic Conceptual Model> <GML > < Geographic Markup Language > <GN > < Geographical Names > <GRS80 > < Geodetic Reference System 1980 > <HY > < Hydrography > <ICAO > < International Civil Aviation Organisation > <ISO > < International Standardisation Organisation > <ITRS > < International Terrestrial Reference System > <JRC > < Joint Research Centre > <LADM > < Land Administration Domain Model > <LC > < Land Cover > <LMO > < Legally Mandated Organisation > <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 Communities > <SE > < Style Encoding > <SU > < Statistical Units> <MS > < Style Layer Descriptor > <TN > < Transport > <TWG > < Thematic Working Group > <URI > < Uniform Resource Identifier > <US > < Utility and Governmental Services > <UTF > < Unicode Transformation Format > <WFS > < Web Feature Service > <WMS > < Web Map Service > <XML > < Extensible Markup Language >



2.6 Notation of requirements and recommendations To make it easier to identify the mandatory requirements and the recommendations for spatial data sets in the text, they are highlighted and numbered.

IR Requirement X Requirements that are reflected in the Implementing Rule on interoperability of spatial data sets and services are shown using this style.

DS Requirement X Requirements that are not reflected in the Implementing Rule on

interoperability of spatial data sets and services are shown using this style.

Recommendation 1 Recommendations are shown using this style.

2.7 Conformance TG Requirement 1 Any dataset claiming conformance with this INSPIRE data specification shall

pass the requirements described in the abstract test suite presented in Annex A.

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 NOTE Since the content of this chapter was redundant with the overview description (section 2) and executive summary, it has been decided that this chapter will be removed in v3.0.



5 Data content and structure This data specification defines the following application schemas:

− The <ApplicationSchema1> application schema …

IR Requirement 1 Spatial data sets related to the theme Buildings shall be made available using the spatial object types and data types specified in the following application schema(s): BuildingBase + BuildingCore2D or BuildingBase + BuildingCore3D.

These spatial object types and data types shall comply with the definitions

and constraints and include the attributes and association roles defined in this section.

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

NOTE The application schema specifies requirements on the properties of each spatial object including its multiplicity, domain of valid values, constraints, etc. All properties have to be reported, if the relevant information is part of the data set. Most properties may be reported as “void”, if the data set does not include relevant information. See the Generic Conceptual Model [DS-D2.5] for more details. In addition to the application schemas listed in IR Requirement 1, additional application schemas have been defined for the theme Buildings. These additional application schemas 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.

Recommendation 2 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): BuildingBase + BuildingExtended2D or BuildingBase + BuildingExtended3D..

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.

NOTE: The extended profiles may be used as a whole (by using the associated GML schema, i.e. the associated .XSD file) or they may be used only partly, i.e. a data producer may extend one of the core profiles respecting the principles given in the Generic Conceptual Model and using some of the additional concepts (feature types, attributes, data types, code lists) defined in the extended profiles of this theme.



5.1 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.1.1 Stereotypes In the application schemas in this sections 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 1 below.

Table 1 – 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. placeholder Class A class that acts as a placeholder for a class, typically a spatial

object type, that will be specified in the future as part of another spatial data theme. The class should at least have a definition, but may otherwise have a preliminary or no specification (see section 5.1.2).

Type Class A conceptual, abstract type that is not a spatial object type. 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. enumeration Class A fixed list of valid identifiers of named literal values. Attributes

of an enumerated type may only take values from this list. 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.1.3).

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.1.2 Placeholder and candidate types Some of the INSPIRE Annex I data specifications (which were developed previously to the Annex II+III data specifications) refer to types that were considered to thematically belong and which were expected to be fully specified in Annex II or III spatial data themes. Two kinds of such types were distinguished:

− Placeholder types were created as placeholders for types (typically spatial object types) that were to be specified as part of a future spatial data theme, but which was already used as a value type of an attribute or association role in this data specification.



Placeholder types received the stereotype «placeholder» and were placed in the application schema package of the future spatial data theme where they thematically belong. For each placeholder, a definition was specified based on the requirements of the Annex I theme. The Annex II+III TWGs were required to take into account these definitions in the specification work of the Annex II or III theme. If necessary, the attributes or association roles in the Annex I data specification(s) that have a placeholder as a value type shall be updated.

− Candidate types were types (typically spatial object types) for which already a preliminary specification was given in the Annex I data specification. Candidate types did not receive a specific stereotype and were placed in the application schema package of the future spatial data theme where they thematically belong. For each candidate type, a definition and attributes and association roles were specified based on the requirements of the Annex I theme. The Annex II+III TWGs were required to take into account these specifications in the specification work of the Annex II or III theme. If the type could not be incorporated in the Annex II or III data specification according to its preliminary specification, it should be moved into the application schema of the Annex I theme where it had first been specified. In this case, the attributes or association roles in the Annex I data specification(s) that have the type as a value type shall be updated if necessary.

NOTE Once the Annex II+III data specifications have been finalised by the TWGs (version 3.0), all placeholders and candidate types should have been removed. In some cases, this may require one or several of the Annex I data specifications (and the Implementing Rule on interoperability of spatial data sets and services) to be updated.

5.1.3 Voidable characteristics

If a characteristic of a spatial object is not present in the spatial data set, but may be present or applicable in the real world, the property shall receive this stereotype. If and only if a property receives this stereotype, the value of void may be used as a value of the property. A void value shall imply that no corresponding value is contained in the spatial data set maintained by the data provider or no corresponding value can be derived from existing values at reasonable costs, even though the characteristic may be present or applicable in the real world. It is possible to qualify a value of void in the data with a reason using the VoidValueReason type. The VoidValueReason type is a code list, which includes the following pre-defined values:

− Unpopulated: The characteristic 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 characteristic receives this value for all 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 on an object-by-object basis in a spatial data set.

NOTE It is expected 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. A value (the real value or void) only needs to be made available for properties that have a minimum cardinality of 1.

5.1.4 Enumerations Enumerations are modelled as classes in the application schemas. Their values are modelled as attributes of the enumeration class using the following modelling style:

− No initial value, but only the attribute name part, is used. − The attribute name conforms to the rules for attributes names, i.e. is a lowerCamelCase name.

Exceptions are words that consist of all uppercase letters (acronyms).

IR Requirement 2 Attributes of spatial object types or data types whose type is an enumeration shall only take values included in the enumeration.

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

5.1.5.1. Obligation For each attribute that has a code list as its value, a tagged value called “obligation” is specified to define the level of obligation to use values from the list. The tagged value can take the following values:

− IR means that only the values defined by the code list shall be used for the attribute. This obligation is also included in the Implementing Rule on interoperability of spatial data and services.

− TG means that only the values defined by the code list should be used for the attribute. This obligation is not included in the Implementing Rule on interoperability of spatial data and services.

IR Requirement 3 Attributes of spatial object types or data types whose type is a code list with an “obligation” value of “IR” shall only take values that are valid according to the code list’s specification.

Recommendation 3 Attributes of spatial object types or data types whose type is a code list with an “obligation” value of “TG” should only take values that are valid according to the code list’s specification.

5.1.5.2. 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, which is managed and governed by the INSPIRE expert group on maintenance and implementation. Change requests to these code lists (e.g. to add, deprecate or supersede values) are processed and decided upon using the maintenance workflows defined by the INSPIRE expert group.

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. 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.

− If the code list is versioned, the Version column specifies which version of the code list shall be used in INSPIRE. The version can be specified using a version number or the publication date of a version. The specification can also refer to the “latest available version”.

− The Availability column specifies from where the values of the externally governed code list are available, through a URL for code lists that are available online, or a citation for code lists that are only available offline.

− In the Formats column the formats are listed, in which a code list is available. These can be machine-readable (e.g. SKOS/RDF, XML) or human-readable (e.g. HTML, PDF).

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

− For encoding values of externally governed code lists, rules have to be specified for generating URI identifiers and labels for code list values. These are specified in a separate table.

5.1.5.3. 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.1.5.4. Extensibility For each code list, a tagged value called “extensibility” is specified to define which additional values (other than those explicitly specified) are allowed as valid values of the code list. The tagged value can take the following values:

− none means that only the values explicitly specified shall / should16 be used for the attribute. − narrower means that only the values explicitly specified or values narrower than the specified

values shall / should be used for the attribute.

16 It depends on the level of the “obligation” tagged value on the attribute, whether this is a requirement or recommendation.



− any means that, in addition to the values explicitly specified, any other value may be used. NOTE The “extensibility” tagged value does not affect the possibility to update the code list values following the formal maintenance procedure. For example, even for code lists, for which the “extensibility” is set to none, it is still possible to add values following the maintenance procedure of the code list. As a result of this update, the code list may include additional valid values, and these additional may be used for attributes having the code list as a type.

5.1.6 Coverages Coverage functions are used to describe characteristics of real-world phenomena that vary over space and/or time. Typical examples are temperature, elevation, precipitation, imagery. A coverage contains a set of such values, each associated with one of the elements in a spatial, temporal or spatio-temporal domain. Typical spatial domains are point sets (e.g. sensor locations), curve sets (e.g. contour lines), grids (e.g. orthoimages, elevation models), etc. In INSPIRE application schemas, coverage functions are defined as properties of spatial object types where the type of the property value is a realisation of one of the types specified in ISO 19123. To improve alignment with coverage standards on the implementation level (e.g. ISO 19136 and the OGC Web Coverage Service) and to improve the cross-theme harmonisation on the use of coverages in INSPIRE, an application schema for coverage types is included in the Generic Conceptual Model in 9.9.4. This application schema contains the following coverage types:

− RectifiedGridCoverage: coverage whose domain consists of a rectified grid – a grid for which there is an affine transformation between the grid coordinates and the coordinates of a coordinate reference system (see Figure 1, left).

− ReferenceableGridCoverage: coverage whose domain consists of a referenceable grid – a grid associated with a transformation that can be used to convert grid coordinate values to values of coordinates referenced to a coordinate reference system (see Figure 1, right).

− MultiTimeInstantCoverage: coverage providing a representation of the time instant/value pairs, i.e. time series (see Figure 2).

Where possible, only these coverage types (or a subtype thereof) are used in INSPIRE application schemas.

(Source: ISO 19136:2007) (Source: GML 3.3.0)

Figure n°9 – Examples of a rectified grid (left) and a referenceable grid (right)



Figure n°10 – Example of a MultiTimeSeriesCoverage (a time series)

5.2 Application schema <base >

5.2.1.1. Narrative description Base application schema is an abstract application schema that describes the features and attributes that are common to all the four instanciable application schemas, namely core2D, core3D, extended2D and extended3D.

5.2.1.1.1. Feature types



class Buildings Base

«featureType»AbstractBuilding

«voidable»+ buildingNature: BuildingNatureValue [0..*]+ currentUse: CurrentUse [0..*]+ numberOfDwell ings: Integer [0..1]+ numberOfBuildingUnits: Integer [0..1]+ numberOfFloorsAboveGround: Integer [0..1]

«featureType»AbstractConstruction

+ inspireId: Identifier

«voidable, l ifeCycleInfo»+ beginLifespanVersion: DateTime+ endLifespanVersion: DateTime [0..1]

«voidable»+ conditionOfConstruction: ConditionOfConstructionValue+ dateOfConstruction: DateOfEvent [0..1]+ dateOfDemolition: DateOfEvent [0..1]+ dateOfRenovation: DateOfEvent [0..1]+ elevation: Elevation [0..*]+ externalReference: ExternalReference [0..*]+ heightAboveGround: HeightAboveGround [0..*]+ name: GeographicalName [0..*]

Figure n° X : feature types of base package

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

o AbstractBuilding is an abstract feature type grouping the common properties of instanciable feature types Building and BuildingPart, that are present in all other application schemas.

o 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.

5.2.1.1.2. 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 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. In case of representation by point and by surface, the surface should be the reference geometry.



«dataType»BuildingGeometry2D

+ geometry: GM_Object+ referenceGeometry: boolean+ horizontalGeometryReference: HorizontalGeometryReferenceValue+ verticalGeometryReference: ElevationReferenceValue [0..1]

«voidable»+ horizontalGeometryEstimatedAccuracy: Length+ verticalGeometryEstimatedAccuracy: Length [0..1]

«codeList»Elev ationReferenceValue

+ aboveGroundEnvelope+ bottomOfConstruction+ entrancePoint+ generalEave+ generalGround+ generalRoof+ generalRoofEdge+ highestEave+ highestGroundPoint+ highestPoint+ highestRoofEdge+ lowestEave+ lowestFloorAboveGround+ lowestGroundPoint+ lowestRoofEdge+ topOfConstruction

tags

extensibil i ty = noneobligation = IRvocabulary = http://inspire.ec.europa.eu/codeList/ElevationReferenceValue

«codeList»HorizontalGeometryReferenceValue

+ aboveGroundEnvelope+ combined+ entrancePoint+ envelope+ footPrint+ lowestFloorAboveGround+ pointInsideBuilding+ pointInsideCadastralParcel+ roofEdge

tags

extensibil i ty = noneobligation = IRvocabulary = http://inspire.ec.europa.eu/codeList/HorizontalGeometryRefrenceValue

Figure n°14: the geometry of Building 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.



Figure n° 15: Examples of HorizontalGeometryReference

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.2.1.1.3. Elevation

«dataType»Elev ation

+ elevationReference: ElevationReferenceValue+ elevationReferenceSystem: VerticalCRSIdentifier+ value: Length

class Elev ationBaseTypes

«dataType»VerticalCRSIdentifier

+ code: CharacterString+ codeSpace: CharacterString+ version: CharacterString [0..1]





tags

extensibil ity = noneobligation = IRvocabulary = http://inspire.ec.europa.eu/codeList/ElevationReferenceValue

Figure n°17: 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 illustrations below) - the elevation may be given in various vertical reference systems; this has to be documented by the attribute elevationReferenceSystem; this attribute is defined as VerticalCRSIdentifier, a data type imported from data specification on theme Elevation.

Recommendation 1 : 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. An example about how to implement the data type VerticalCRSIdentifier is given in the Data capture clause.



Figure n°18 : Examples of elevation references for different kinds of building

5.2.1.1.4. 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.

«dataType»HeightAbov eGround

+ value: Length

«voidable»+ heightReference: ElevationReferenceValue+ lowReference: ElevationReferenceValue+ status: HeightStatusValue

«codeList»HeightStatusValue

+ estimated+ measured

tags

extensibi li ty = noneobligation = IRvocabulary = http://inspire.ec.europa.eu/codeList/HeightStatusValue

«codeList»

Elev ationReferenceValue


tags


Figure n° 19 : the HeightAboveGround data type

It is recommended to use:

• For the low reference



- generalGround - lowestGroundPoint - lowestFloorAboveGround - highestGroundPoint - entrancePoint

• For the high reference - generalRoofEdge - lowestRoofEdge - highestRoofEdge - generalEave - lowestEave - highestEave - generalRoof - top OfConstruction - highestPoint

5.2.1.1.5. 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 Data Capture clause.



class Buildings - Base: Code Lists

residential individualResidence collectifeResidence twoDwellings moreThanTwoDwell ings residenceFor CommunitiesagricultureindustrialcommerceAndServices office trade publicServicesancillary


«codeList»BuildingNatureValue

+ arch+ bunker+ canopy+ castle+ caveBuilding+ chapel+ church+ dam+ greenhouse+ l ighthouse+ mosque+ shed+ silo+ stadium+ storageTank+ synagogue+ temple+ tower+ windmil l+ windTurbine

tags

extensibil ity = anyobligation = IRvocabulary = http://inspire.ec.europa.eu/codeList/BuildingNatureValue

Figure n° 20: code lists for classification of buildings

arch arch bunker canopy canopy

castle castle caveBuilding caveBuilding chapel

Chapel church church dam dam



greenhouse greenhouse lighthouse mosque shed

shed silo stadium stadium storageTank

synagogue temple temple tower tower

tower tower transformer windmill windTurbine Figure n° 21: building nature

5.2.1.1.6. Attribute externalReference

class Buildings - Base: Data Types

«dataType»ExternalReference

+ informationSystem: URI+ informationSystemName: PT_FreeText+ reference: CharacterString

Figure n° 22: 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.2.1.2. UML Overview

class Buildings Base







Feature types



class Buildings - Base: Data Types

«dataType»ExternalReference

+ informationSystem: URI+ informationSystemName: PT_FreeText+ reference: CharacterString

«dataType»CurrentUse

+ currentUse: CurrentUseValue

«voidable»+ percentage: Integer

«dataType»HeightAbov eGround

+ value: Length

«voidable»+ heightReference: ElevationReferenceValue+ lowReference: ElevationReferenceValue+ status: HeightStatusValue

«dataType»DateOfEv ent

«voidable»+ anyPoint: DateTime [0..1]+ beginning: DateTime [0..1]+ end: DateTime [0..1]

«dataType»BuildingGeometry2D



«dataType»Elev ation

+ elevationReference: ElevationReferenceValue+ elevationReferenceSystem: VerticalCRSIdentifier+ value: Length

geometryIsPointOrSurfaceOrMultiSurface/*Geometry must be GM_Point or GM_Surface or GM_MultiSurface.*/

verticalGeometryEstimatedAccuracyUoMIsMetre/*Value of verticalGeometryEstimatedAccuracy has to be given in meters.*/inv: self.verticalGeometryEstimatedAccuracy.uom.uomSymbol='m'

horizontalGeometryEstimatedAccuracyUoMIsMetre/*Value of horizontalGeometryEstimatedAccuracy has to be given in meters. */inv: self.horizontalGeometryEstimatedAccuracy.uom.uomSymbol='m'

atLeastOneEvent/*At least, one of the attributes beginning, end or anyPoint shall be supplied.*/inv: dateOfEvent->notEmpty()

Data types






tags


«codeList»CurrentUseValue

+ residential+ individualResidence+ collectiveResidence+ twoDwellings+ moreThanTwoDwellings+ residenceForCommunities+ agriculture+ industrial+ commerceAndServices+ office+ trade+ publicServices+ ancill lary

tags

extensiblity = narrowerobligation = IRvocabulary = http://inspire.ec.europa.eu/codeList/CurrentUseValue

«codeList»BuildingNatureValue

+ arch+ bunker+ canopy+ castle+ caveBuilding+ chapel+ church+ dam+ greenhouse+ lighthouse+ mosque+ shed+ silo+ stadium+ storageTank+ synagogue+ temple+ tower+ windmill+ windTurbine

tags

extensibil ity = anyobl igation = IRvocabulary = http://inspire.ec.europa.eu/codeList/BuildingNatureValue

«codeList»HorizontalGeometryReferenceValue

+ aboveGroundEnvelope+ combined+ entrancePoint+ envelope+ footPrint+ lowestFloorAboveGround+ pointInsideBuilding+ pointInsideCadastralParcel+ roofEdge

tags

extensibil ity = noneobligation = IRvocabulary = http://inspire.ec.europa.eu/codeList/HorizontalGeometryRefrenceValue

«codeList»HeightStatusValue

+ estimated+ measured

tags

extensibil ity = noneobligation = IRvocabulary = http://inspire.ec.europa.eu/codeList/HeightStatusValue

«codeList»ConditionOfConstructionValue

+ declined+ demolished+ functional+ projected+ ruin+ underConstruction

tags

extensibil i ty = noneobligation = IRvocabulary = http://inspire.ec.europa.eu/codeList/ConditionOfConstructionValue

residential individualResidence collectifeResidence twoDwellings moreThanTwoDwellings residenceFor CommunitiesagricultureindustrialcommerceAndServices office trade publicServicesancillary

Code lists



5.2.2 Feature catalogue

Feature catalogue metadata

Feature catalogue name INSPIRE feature catalogue BuildingsBase Scope BuildingsBase Version number 2.9 Version date 2012-07-09 Definition source INSPIRE data specification BuildingsBase

Types defined in the feature catalogue

Type Package Stereotypes Section AbstractBuilding BuildingsBase «featureType» 5.2.2.1.1 AbstractConstruction BuildingsBase «featureType» 5.2.2.1.2 BuildingGeometry2D BuildingsBase «dataType» 5.2.2.2.1 BuildingNatureValue BuildingsBase «codeList» 5.2.2.3.1 ConditionOfConstructionValue BuildingsBase «codeList» 5.2.2.3.2 CurrentUse BuildingsBase «dataType» 5.2.2.2.2 CurrentUseValue BuildingsBase «codeList» 5.2.2.3.3 DateOfEvent BuildingsBase «dataType» 5.2.2.2.3 Elevation BuildingsBase «dataType» 5.2.2.2.4 ElevationReferenceValue BuildingsBase «codeList» 5.2.2.3.4 ExternalReference BuildingsBase «dataType» 5.2.2.2.5 HeightAboveGround BuildingsBase «dataType» 5.2.2.2.6 HeightStatusValue BuildingsBase «codeList» 5.2.2.3.5 HorizontalGeometryReferenceValue BuildingsBase «codeList» 5.2.2.3.6

5.2.2.1. Spatial object types

5.2.2.1.1. AbstractBuilding

AbstractBuilding (abstract) Name: Abstract Building Subtype of: AbstractConstruction Definition: Abstract feature type grouping the common properties of instanciable feature

types Building and BuildingPart. Description: NOTE: In base application schema, feature type AbstractBuilding includes only

the common semantic properties of Building and BuildingPart. Status: Proposed Stereotypes: «featureType» Identifier: null Attribute: buildingNature

Value type: BuildingNatureValue Definition: Characteristic of the building that makes it generally of interest for mappings

applications. 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. Currently, there is a very short and quite 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. NOTE: the characteristic may be related to the physical aspect and/or to the function of the building.



AbstractBuilding (abstract) Multiplicity: 0..* Stereotypes: «voidable» Obligation: Implementing Rule (requirement) Attribute: currentUse

Value type: CurrentUse Definition: Activity hosted by the real world object. Description: NOTE: This attribute addresses mainly the buildings hosting human activities.

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

Value type: Integer Definition: Number of dwellings in the real world object. Multiplicity: 0..1 Stereotypes: «voidable» Attribute: numberOfBuildingUnits

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: BuildingUnit is a feature type aimed at subdividing a whole building or a building part into smaller parts that are treated as seperate entities in daily life. A BuildingUnit 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: 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.

Multiplicity: 0..1 Stereotypes: «voidable» Attribute: numberOfFloorsAboveGround

Value type: Integer Definition: Number of floors above ground of the real world object. Multiplicity: 0..1 Stereotypes: «voidable»

5.2.2.1.2. AbstractConstruction

AbstractConstruction (abstract) Name: Abstract Construction Definition: Abstract feature type grouping the semantic properties of building, building parts

and of some optional feature types that may be added to core profile, in order to provide more information about theme Buildings.

Description: The optional feature types that may be added to core profile are described in the extended profile. The ones inheriting from the attributes of AbstractConstruction are Installation and OtherConstruction.

Status: Proposed Stereotypes: «featureType» Identifier: null



AbstractConstruction (abstract)

Attribute: 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: conditionOfConstruction

Value type: ConditionOfConstructionValue Definition: Status of construction of the real-world object. Multiplicity: 1 Stereotypes: «voidable» Obligation: Implementing Rule (requirement) Attribute: dateOfConstruction

Value type: DateOfEvent Multiplicity: 0..1 Stereotypes: «voidable» Attribute: dateOfDemolition

Value type: DateOfEvent Definition: Date of demolition of the real world object. Multiplicity: 0..1 Stereotypes: «voidable» Attribute: dateOfRenovation

Value type: DateOfEvent Definition: Date of last major renovation of the real world object. Multiplicity: 0..1 Stereotypes: «voidable» Attribute: elevation

Value type: Elevation Definition: Vertical-constrained dimensional property of the real world object 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 theme Elevation.

Multiplicity: 0..* Stereotypes: «voidable» Attribute: 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» Attribute: externalReference

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



AbstractConstruction (abstract) 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

Value type: HeightAboveGround Definition: Height above ground of the real world object. 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

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: NOTE 1: 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: name

Value type: GeographicalName Definition: Name of the real world object. Description: Examples: Big Ben, Eiffel Tower, Sacrada Familia Multiplicity: 0..* Stereotypes: «voidable» Association role: groupingFacility

Value type: ProductionFacility Multiplicity: 0..*

5.2.2.2. Data types

5.2.2.2.1. BuildingGeometry2D

BuildingGeometry2D Name: Building Geometry2D Definition: This data types includes the geometry of the building and metadata information

about which element of the building was captured and how. Status: Proposed Stereotypes: «dataType» Identifier: null Attribute: verticalGeometryEstimatedAccuracy



BuildingGeometry2D Value type: Length Definition: The estimated absolute positional accuracy of the Z coordinates of the geometry

of the building, 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: geometry

Value type: GM_Object Definition: Geometric representation of the building as 2D or 2,5D data. Multiplicity: 1 Attribute: referenceGeometry

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

recommended to provide the surface as reference geometry. NOTE 2: The referenceGeometry may also be used preferably for spatial queries by download services (WFS) or by Geographical Information System (GIS).

Multiplicity: 1 Obligation: null Attribute: horizontalGeometryReference

Value type: HorizontalGeometryReferenceValue Definition: Element of the building that was captured by (X,Y) coordinates. Multiplicity: 1 Obligation: Implementing Rule (requirement) Attribute: verticalGeometryReference

Value type: ElevationReferenceValue Definition: Element of the building that was captured by vertical coordinates. Multiplicity: 0..1 Obligation: Implementing Rule (requirement) Attribute: horizontalGeometryEstimatedAccuracy

Value type: Length Definition: The estimated absolute positional accuracy of the (X,Y) coordinates of the

geometry of the building, 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» Constraint: geometryIsPointOrSurfaceOrMultiSurface



BuildingGeometry2D Natural

language: Geometry must be GM_Point or GM_Surface or GM_MultiSurface.

OCL: Constraint: horizontalGeometryEstimatedAccuracyUoMIsMetre

Natural language:

Value of horizontalGeometryEstimatedAccuracy has to be given in meters.

OCL: inv: self.horizontalGeometryEstimatedAccuracy.uom.uomSymbol='m' Constraint: verticalGeometryEstimatedAccuracyUoMIsMetre

Natural language:

Value of verticalGeometryEstimatedAccuracy has to be given in meters.

OCL: inv: self.verticalGeometryEstimatedAccuracy.uom.uomSymbol='m'

5.2.2.2.2. CurrentUse

CurrentUse Name: Current Use Definition: This data type enables to detail the current use(s) of the real world object. Status: Proposed Stereotypes: «dataType» Identifier: null Attribute: currentUse

Value type: CurrentUseValue Definition: The current use or one of the current uses of the real world object. Description: EXAMPLE: trade Multiplicity: 1 Obligation: Implementing Rule (requirement) Attribute: 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.2.2.2.3. DateOfEvent

DateOfEvent Name: Date Of Event Definition: This data type includes the different possible ways to define the date of an event. Status: Proposed Stereotypes: «dataType» Identifier: null Attribute: anyPoint



DateOfEvent 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

Value type: DateTime Definition: Date and time when the event begun. Multiplicity: 0..1 Stereotypes: «voidable» Attribute: 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() 5.2.2.2.4. Elevation

Elevation Name: Elevation Definition: This data types includes the elevation of the real world object and information

about how this elevation was measured. Status: Proposed Stereotypes: «dataType» Identifier: null Attribute: elevationReference

Value type: ElevationReferenceValue Definition: Element of the real world object where the elevation was measured. Multiplicity: 1 Obligation: Implementing Rule (requirement) Attribute: elevationReferenceSystem

Value type: VerticalCRSIdentifier Definition: The vertical coordinate reference system used to measure the elevation. Multiplicity: 1 Attribute: value

Value type: Length Definition: Value of the Elevation of the real world object. Multiplicity: 1 Constraint: UoMofLengthIsMetre

Natural language:

Value of Elevation has to be given in meter.

OCL: inv: self.value.uom.uomSymbol='m'

5.2.2.2.5. ExternalReference

ExternalReference



ExternalReference Name: External Reference Definition: Reference to an external information system containing any piece of information

related to the spatial object. Status: Proposed Stereotypes: «dataType» Identifier: null Attribute: informationSystem

Value type: URI Definition: Uniform Resource Identifier of the external information system. Multiplicity: 1 Attribute: informationSystemName

Value type: PT_FreeText Definition: The name of the external information system. Description: EXAMPLES: Danish Register of Dwellings, Spanish Cadastre. Multiplicity: 1 Attribute: 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.2.2.2.6. HeightAboveGround

HeightAboveGround Name: Height Above Ground Definition: This data type includes the height above ground of the real world object and

information about how this height was captured. Status: Proposed Stereotypes: «dataType» Identifier: null Attribute: heightReference

Value type: ElevationReferenceValue Definition: Element of the real world object used as the high reference for capturing its

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

building. Multiplicity: 1 Stereotypes: «voidable» Obligation: Implementing Rule (requirement) Attribute: lowReference

Value type: ElevationReferenceValue Definition: Element of the real world object used as the low reference for capturing its

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

ground point.



HeightAboveGround Multiplicity: 1 Stereotypes: «voidable» Obligation: Implementing Rule (requirement) Attribute: status

Value type: HeightStatusValue Definition: The way the height has been captured. Multiplicity: 1 Stereotypes: «voidable» Obligation: Implementing Rule (requirement) Attribute: value

Value type: Length Definition: Value of the height above ground of the real world object. Multiplicity: 1 Constraint: valueUoMIsMetre

Natural language:

Value has to be in meters.

OCL: inv: self.value.uom.uomSymbol='m'

5.2.2.3. Code lists

5.2.2.3.1. BuildingNatureValue

BuildingNatureValue Name: Building Nature Definition: List of possible values for the nature of a building. Status: Proposed Stereotypes: «codeList» Extensibility: any Identifier: http://inspire.ec.europa.eu/codeList/BuildingNatureValue Value: mosque

Definition: A building or structure whose primary purpose is to facilitate the muslim cult. Value: shed

Definition: A building of light construction, which usually has one or more open sides, that is typically used for storage.

Value: silo

Definition: A large storage structure, generally cylindrical, used for storing loose materials. Description: EXAMPLES: Grain, cement storage. Value: stadium

Definition: A place or venue for sports, concerts or other events and consists of a field or stage either partly or completely surrounded by a structure designed to allow spectators to stand or sit and view the event.

Description: EXAMPLES: Arena, amphitheatre, stadium. Value: storageTank

Definition: A container usually for holding liquids and compressed gases. Value: synagogue

Definition: A building or structure whose primary purpose is to facilitate the israelit cult.



BuildingNatureValue

Value: temple

Definition: A building or structure whose primary purpose is to facilitate the meeting of a religious sect.

Description: Temples dedicated to catholique/orthodox, muslim or israelit cults should preferebly be classified as church, mosque or synagogue.

Value: tower

Definition: A relatively tall, narrow structure that may either stand alone or may form part of another structure.

Description: EXAMPLES: Clock tower, church tower, control tower, minaret, cooling tower, fire look-out tower, mirador, telecommunication tower.

Value: windmill

Definition: A building which converts the energy of the wind into rotational motion by means of adjustable sails or blades.

Value: windTurbine

Definition: A tower and associated equipment that generates electrical power from wind. Value: arch

Definition: A man-made structure in the form of an arch. Description: EXAMPLES: city gates, triumph archs. Value: bunker

Definition: A facility, partly underground, intended or used by the military either for location of command/control centers or for troop encampment.

Value: canopy

Definition: An overhead roof providing shelter to things below. Canopies may be free standing frameworks over which a covering is attached or may be linked or suspended to the outside of a building.

Value: castle

Definition: A large ornate or fortified building usually constructed for the purpose of a private residence or security.

Description: Includes palaces, forts and castles. Value: caveBuilding

Definition: A space hosting human or economic activity which is usually enclosed within rock with the addition of man-made exterior walls and which may contain structures comparable to the interior structures of freestanding buildings.

Value: chapel

Definition: A Christian place of worship, usually smaller than a church. Value: church

Definition: A building or structure whose primary purpose is to facilitate the catholic or orthodox cult.

Description: Includes churches and cathedrals. Value: dam

Definition: A permanent barrier across a watercourse used to impound water or to control its flow.

Description: Only dams hosting rooms for workers and/or machinery are under scope of theme Buildings.



BuildingNatureValue

Value: greenhouse

Definition: A building that is often constructed primarily of transparent material (for example: glass), in which temperature and humidity can be controlled for the cultivation and/or protection of plants.

Value: lighthouse

Definition: A tower designed to emit light from a system of lamps and lenses. 5.2.2.3.2. ConditionOfConstructionValue

ConditionOfConstructionValue Name: Condition Of Construction Definition: List of possible values for the condition of a construction of a real world object. Status: Proposed Stereotypes: «codeList» Extensibility: none Identifier: http://inspire.ec.europa.eu/codeList/ConditionOfConstructionValue Value: declined

Definition: The real world object can not be used under normal conditions, though its main elements (walls, roof) are still present.

Description: EXAMPLE: A house whose windows have been for a long time broken or walled up (even if occupied by squatters).

Value: demolished

Definition: The real world object has been demolished. There are no more visible remains. Value: functional

Definition: The real world object is functional. Description: NOTE: The construction may be used under normal conditions for its current use

value(s). Value: projected

Definition: The real world object is being designed. Construction has not yet started. Value: ruin

Definition: The real world object has been partly demolished and some main elements (roof, walls) have been destroyed. There are some visible remains of the construction.

Value: underConstruction

Definition: The real world object is under construction and not yet functional. This applies only to the initial construction of the real world object and not to maintenance work.

5.2.2.3.3. CurrentUseValue

CurrentUseValue Name: Current Use Definition: List of possible values for the current use of the real world object. 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).

Status: Proposed Stereotypes: «codeList» Extensibility: any Identifier: http://inspire.ec.europa.eu/codeList/CurrentUseValue



CurrentUseValue

Value: residential

Definition: The real world object is used for residential purpose. Value: individualResidence

Definition: The real world object hosts only one dwelling. Description: NOTE: This value includes detached houses such as bungalows, villas, chalets,

forest lodges, farmhouses, country houses, summer houses, weekend houses … and semi-detached or terraced houses, with each dwelling having its own roof and its own entrance directly from ground surface. Parent: residential

Value: collectiveResidence

Definition: The real world object hosts more than one dwelling. Parent: residential Value: twoDwellings

Definition: The real world object hosts two dwellings. Description: NOTE: This class includes detached houses, semi-detached or terraced houses,

with two dwellings. Parent: collectiveResidence

Value: moreThanTwoDwellings

Definition: The real world object hosts at least 3 dwellings. Description: NOTE: This class includes flat blocks, apartment houses, with three or more

dwellings but excludes residence for communities. Parent: collectiveResidence

Value: residenceForCommunities

Definition: The real world object hosts a residence for communities. Description: This class includes residential buildings for communities, including residences

and service residences for the elderly, students, children and other social groups. Parent: residential

Value: agriculture

Definition: The real world object is used for agricultural activities. Value: industrial

Definition: The real world object is used for secondary sector activities (industrial). Value: commerceAndServices

Definition: The real world object is used for any service activities. This value addresses the buildings and building components dedicated to tertiary sector activities (commercial and services).

Description: NOTE: This value includes both ternary sector (commercial activities) and quaternary sector (non-commercial, charity sector).

Value: office

Definition: The real world object hosts offices. Parent: commerceAndServices Value: trade

Definition: The real world object hosts trade activities. Parent: commerceAndServices Description: EXAMPLE: Shops, supermarkets, hotels, restaurants. Value: publicServices

Definition: The real world object hosts public services. Public services are tertiary services provided for the benefit of the citizens.



CurrentUseValue Description: Public services are often ruled by public governments or on behalf of them.

EXAMPLES: Schools, hospitals, governmental buildings, prisons, rescue stations, transport station. NOTE: in case of a building being both office and public service (e.g. a city hall), the building should be classified preferably as public service. Parent: commerceAndServices

Value: ancilllary

Definition: A real world object of small size that is used only in connection with another larger real world object and generally does not inherit the same function and characteristics as the real world object to which it is linked.

Description: EXAMPLES : A summer house or garage (ancillary use) in the garden of a dwelling (residential use).

5.2.2.3.4. ElevationReferenceValue

ElevationReferenceValue Name: Elevation Reference Definition: List of possible values for the element of the real world object that has been

considered to capture its 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.

Status: Proposed Stereotypes: «codeList» Extensibility: none Identifier: http://inspire.ec.europa.eu/codeList/ElevationReferenceValue Value: aboveGroundEnvelope

Definition: The elevation has been captured at the level of the maximum extend of the above ground envelope of the real world object.

Value: bottomOfConstruction

Definition: The elevation has been captured at the bottom of the usable part of the real world object.

Description: Note: The bottom of usable part of a building is generally its lowest underground floor.

Value: entrancePoint

Definition: The elevation has been captured at the entrance of the real world object, generally the bottom of the main entrance door.

Value: generalEave

Definition: The elevation has been captured at eave level, anywhere between the lowest and the highest eave levels of the real world object.

Description: NOTE: in case ofa roof having a symetry axis, values generalEave, lowestEave and highestEave are equivalent.

Value: generalGround

Definition: The elevation has been captured at ground level, anywhere between the lowest and the highest ground points of the real world object.

Description: NOTE: In case of buildings located on flat areas, values generalGround, lowestGroundPoint and highestGroundPoint are equivalent

Value: generalRoof



ElevationReferenceValue Definition: The elevation has been captured at roof level, anywhere between the lowest

edge roof level and the top of the real world object. Value: generalRoofEdge

Definition: The elevation has been captured at roof edge level, anywhere between the lowest and the highest roof edges of the real world object.

Description: NOTE: in case ofa roof having a symetry axis, values generalRoofEdge, lowestRoofEdge and highestRoofEdge are equivalent.

Value: highestEave

Definition: The elevation has been captured at the highest eave level of the real world object.

Value: highestGroundPoint

Definition: The elevation has been captured at the highest ground point of the real world object.

Value: highestPoint

Definition: The elevation has been captured at the highest point of the real world object, including the installations, such as chimneys and antennas.

Value: highestRoofEdge

Definition: The elevation has been captured at the highest roof edge level of the real world object.

Value: lowestEave

Definition: The elevation has been captured at the lowest eave level of the real world object. Value: lowestFloorAboveGround

Definition: The elevation has been captured at the level of the lowest floor above ground of the real world object.

Description: This value is of interest for over-hanging buildings or for buildings on pilotis. Value: lowestGroundPoint

Definition: The elevation has been captured at the lowest ground point level of the real world object.

Value: lowestRoofEdge

Definition: The elevation has been captured at the lowest roof edge level of the real world object.

Value: topOfConstruction

Definition: The elevation has been captured at the top level of the real world object. Description: NOTE: for buildings, it is generally top of the roof.

5.2.2.3.5. HeightStatusValue

HeightStatusValue Name: Height Status Definition: List of possible values for the method used to capture height of the real world

object. Status: Proposed Stereotypes: «codeList» Extensibility: none Identifier: http://inspire.ec.europa.eu/codeList/HeightStatusValue Value: estimated



HeightStatusValue Definition: The height has been estimated and not measured. Description: EXAMPLE 1: Typically, the height has been estimated from the number of floors.

EXAMPLE 2: In some cases, the height has been estimated by interpolation of a set of heights of adjacent buildings.

Value: measured

Definition: The height has been (directly or indirectly) measured. Description: EXAMPLE: typically, the elevation at ground level and at roof level has been

measured by stereo-plotting or by field survey or by cross-referencing with DTM (Digital Terrain Model).

5.2.2.3.6. HorizontalGeometryReferenceValue

HorizontalGeometryReferenceValue Name: Horizontal Geometry Reference Definition: List of possible values for the element of the real world object that has been

considered to capture its horizontal geometry. Description: NOTE: The building component may be a BuildingPart or a BuildingUnit or a

Room. Status: Proposed Stereotypes: «codeList» Extensibility: none Identifier: http://inspire.ec.europa.eu/codeList/HorizontalGeometryRefrenceValue Value: aboveGroundEnvelope

Definition: The real world object horizontal geometry has been captured using the above ground envelope of the real world object, i.e. the maximum extent of the real world object above ground.

Value: combined

Definition: The building horizontal geometry has been obtained from the combination of the geometries of its building parts with the building parts geometries using different horizontal geometry references.

Description: EXAMPLE: A building with two building parts, one captured by its footprint and the other by its lowest floor above ground, and whose geometry is obtained by merging the geometries of the building parts.

Value: entrancePoint

Definition: The real world object geometry is represented by a point located at the entrance of the the real world object.

Value: envelope

Definition: The real world object horizontal geometry has been captured using the whole envelope of the real world object, i.e. the maximum extent of the real world object above and under ground.

Value: footPrint

Definition: The real world object horizontal geometry has been captured using the footprint of the real world object, i.e. its extent at ground level.

Value: lowestFloorAboveGround

Definition: The real world object component horizontal geometry has been captured using the lowest floor above ground of the real world object.

Description: This value is of interest for over-hanging buildings or for buildings on pilotis. Value: pointInsideBuilding



HorizontalGeometryReferenceValue Definition: The real world object horizontal geometry is represented by a point located within

the real world object. Value: pointInsideCadastralParcel

Definition: The real world object horizontal geometry is represented by a point located within the parcel the real world object belongs to.

Value: roofEdge

Definition: The real world object horizontal geometry has been captured using the roof edges of the real world object.

Description: NOTE: This value may be used more generally when the building horizontal geometry has been captured by the roof extent.

5.2.2.4. Imported types (informative)

This section lists definitions for feature types, data types and enumerations 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.2.2.4.1. CharacterString

CharacterString Package: INSPIRE Consolidated UML Model::Foundation Schemas::ISO TC211::ISO

19103:2005 Schema Language::Basic Types::Primitive::Text [Include reference to the document that includes the package, e.g. INSPIRE data specification, ISO standard or the GCM]

5.2.2.4.2. DateTime

DateTime Package: INSPIRE Consolidated UML Model::Foundation Schemas::ISO TC211::ISO

19103:2005 Schema Language::Basic Types::Primitive::Date and Time [Include reference to the document that includes the package, e.g. INSPIRE data specification, ISO standard or the GCM]

5.2.2.4.3. GM_Object

GM_Object (abstract) Package: INSPIRE Consolidated UML Model::Foundation Schemas::ISO TC211::ISO

19107:2003 Spatial Schema:: Geometry::Geometry root [Include reference to the document that includes the package, e.g. INSPIRE data specification, ISO standard or the GCM]

5.2.2.4.4. GeographicalName

GeographicalName Package: INSPIRE Consolidated UML Model::Themes::Annex I::Geographical

Names::Geographical Names [Include reference to the document that includes the package, e.g. INSPIRE data specification, ISO standard or the GCM]

Definition: Proper noun applied to a real world entity. 5.2.2.4.5. Identifier

Identifier Package: INSPIRE Consolidated UML Model::Generic Conceptual Model::Base

Types::Base Types [Include reference to the document that includes the package, e.g. INSPIRE data specification, ISO standard or the GCM]

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.



Identifier 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.2.2.4.6. Integer

Integer Package: INSPIRE Consolidated UML Model::Foundation Schemas::ISO TC211::ISO

19103:2005 Schema Language::Basic Types::Primitive::Numerics [Include reference to the document that includes the package, e.g. INSPIRE data specification, ISO standard or the GCM]

5.2.2.4.7. Length

Length Package: INSPIRE Consolidated UML Model::Foundation Schemas::ISO TC211::ISO

19103:2005 Schema Language::Basic Types::Derived::Units of Measure [Include reference to the document that includes the package, e.g. INSPIRE data specification, ISO standard or the GCM]

5.2.2.4.8. PT_FreeText

PT_FreeText Package: INSPIRE Consolidated UML Model::Foundation Schemas::ISO TC211::ISO

19139 Metadata - XML Implementation::Cultural and linguistic adapdability [Include reference to the document that includes the package, e.g. INSPIRE data specification, ISO standard or the GCM]

5.2.2.4.9. ProductionFacility

ProductionFacility Package: INSPIRE Consolidated UML Model::Themes::Annex III::Production and Industrial

Facilities::ProductionAndIndustrialFacilities [Include reference to the document that includes the package, e.g. INSPIRE data specification, ISO standard or the GCM]

Definition: Something designed, built, installed to serve a specific function with production purposes, comprehending the complete equipment or apparatus for a particular process or operation.

Description: A production facility groups together a single installation, set of installations or production processes (stationary or mobile), which can be defined within a single geographical boundary, organizational unit or production process. A production facility can also be identified as one or more installations located on the same site that are operated by the same natural or legal person and in which production activities are being carried out. Such a facility groups potentially the land, buildings, and equipment used in carrying on an industrial business or other undertaking or service.

5.2.2.4.10. URI

URI Package: INSPIRE Consolidated UML Model::Foundation Schemas::ISO TC211::ISO

19136 GML::basicTypes [Include reference to the document that includes the package, e.g. INSPIRE data specification, ISO standard or the GCM]

5.2.2.4.11. VerticalCRSIdentifier

VerticalCRSIdentifier



VerticalCRSIdentifier Package: INSPIRE Consolidated UML Model::Themes::Annex

II::Elevation::ElevationBaseTypes [Include reference to the document that includes the package, e.g. INSPIRE data specification, ISO standard or the GCM]

Definition: Identifier of the vertical reference system. Description: EXAMPLE DVR90.

5.3 Application schema <core 2D >

5.3.1 Description

5.3.1.1. Narrative description Core2D data is the normative profile for 2D and 2,5D data. Its semantic is based on the data widely used, widely available and whose harmonisation is required at European level, e.g. for homogeneous reporting on Environmental Directives

5.3.1.1.1. Feature types Core 2D application schema inherits from base application schema and moreover, includes 2 instanciable feature types: Building and BuildingPart. 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:

Figure n°11 : From City GML

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.

One Building with 2 BuildingParts



Buildings and BuildingParts share the same set of properties of geometric and semantics properties (i.e. a BuildingPart may be considered as a building). These common properties are factorised in 2 abstract feature types:

- feature AbstractBuilding gathers the common semantics properties; these properties are the same in core2D and core3D profiles

- feature type AbstractBuilding2D inherits of the common semantics properties of AbstractBuilding and includes the 2D geometry of buildings

Figure n°12: a building may be composed of building parts.

A Building may be an aggregation of several BuildingParts or may exist by itself. This is expressed by the multiplicity 0…* of the aggregation.

5.3.1.1.2. Geometry of buildings 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 core2D 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.



Figure n° 16: example for value “combined”


class Buildings - Core 2D

«featureType»BuildingsBase::AbstractBuilding

«voidable»+ buildingNature: BuildingNatureValue [0..*]+ currentUse: CurrentUse [0..*]+ numberOfDwel lings: Integer [0..1]+ numberOfBuildingUnits: Integer [0..1]+ numberOfFloorsAboveGround: Integer [0..1]

«featureType»Building

«featureType»BuildingPart

«dataType»BuildingsBase::BuildingGeometry2D



«featureType»BuildingsBase::AbstractConstruction




Buildings - Base


+ geometry2D: BuildingGeometry2D [1..*]

singleReferenceGeometry/*Exactly one geometry2D attribute must be a reference geometry, i.e. the referenceGeometry attribute must be true.*/inv: sel f.geometry2D->select(referenceGeometry=true)->size() = 1

+parts«voidable»

0..*

Figure n° 23 – UML class diagram: Overview of the BuildingCore2D application schema

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.



5.3.1.3. Consistency between spatial data sets The 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.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 core2D profile 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.

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

5.3.1.6. Geometry representation

IR Requirement 4 The value domain of spatial properties used in this specification shall be restricted to the Simple Feature spatial schema as defined by EN ISO 19125-1.

NOTE The specification restricts the spatial schema to 0-, 1-, 2-, and 2.5-dimensional geometries where all curve interpolations are linear. NOTE 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 3 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.



Figure n° 26: the 2D representations of these buildings are overlapping (this case of overlap is

allowed)

Recommendation 4 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.

This continuous building on piles is represented by its footprint as a multisurface

The building is composed of a block building and of towers that are connected in real world but the building is represented as multi-surface, due to

data capture rules. Figue n°27: examples where multi-surface may be used.

5.3.1.7. 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".

Recommendation 5 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".

NOTE: more detailed explanations about how to use the temporal attributes are supplied in the data capture clause.





Feature catalogue name INSPIRE feature catalogue BuildingCore2D Scope BuildingCore2D Version number 2.9 Version date 2012-07-09 Definition source INSPIRE data specification BuildingCore2D


Type Package Stereotypes Section AbstractBuilding BuildingCore2D «featureType» 5.2.2.1.1 Building BuildingCore2D «featureType» 5.2.2.1.2 BuildingPart BuildingCore2D «featureType» 5.2.2.1.3



AbstractBuilding (abstract) Name: Abstract Building Subtype of: AbstractBuilding Definition: Abstract feature type grouping the common properties of instanciable feature

types Building and BuildingPart. Description: In core 2D application schema, feature type AbstractBuilding includes both the

common semantic properties of Building and BuildingPart (by inheritance from feature type AbstractBuilding of base application schema) and the common geometric properties of Building and BuildingPart.

Status: Proposed Stereotypes: «featureType» Identifier: null Attribute: geometry2D

Value type: BuildingGeometry2D Definition: Geometric representation of the building, as 2D or 2,5D data. 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.3.2.1.2. Building

Building 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.

Status: Proposed Stereotypes: «featureType»



Building Identifier: null 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.3. BuildingPart

BuildingPart 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 BuildingParts having different heights above ground.





AbstractBuilding (abstract) Package: INSPIRE Consolidated UML Model::Themes::Annex

III::Buildings::BU::BuildingsBase [Include reference to the document that includes the package, e.g. INSPIRE data specification, ISO standard or the GCM]

Definition: Abstract feature type grouping the common properties of instanciable feature types Building and BuildingPart.

Description: NOTE: In base application schema, feature type AbstractBuilding includes only the common semantic properties of Building and BuildingPart.


BuildingGeometry2D Package: INSPIRE Consolidated UML Model::Themes::Annex


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



5.4 Application schema <core3D >

5.4.1 Description

5.4.1.1. Narrative description

5.4.1.1.1. General approach Core 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. It is a simple application schema that inherits from the basic semantics of base application schema and that allows all the levels of detail of CityGML building model. The application schema is very similar to the application schema of Core2D profile. The only difference is the geometric representation.

Figure n° 28: Core3D profile inherits from the common semantics of base application schema

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

a. 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”

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

c. 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 core 3D 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.

Figure n° 32 : The 4 levels of detail of City GML

This means that it is possible, for instance:

o to choose one LoD and to use it for all buildings in the data set o to use, in same data set, LoD1 for some buildings, LoD2 for some others and LoD3 or

LoD4 for the last ones. o 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 core 3D 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.




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

MandatoryGeometryA BuildingPart must provide at least one geometry3D.

+parts«voidable»

0..*

Figure n° 33: 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}).

5.4.1.1.2. Types of building geometry




«dataType»BuildingGeometry3DLoD1

«voidable»+ horizontalGeometryReference: HorizontalGeometryReferenceValue [0..1]+ verticalGeometryReference3DTop: ElevationReferenceValue [0..1]

«dataType»BuildingGeometry3DLoD

+ geometryMultiSurface: GM_MultiSurface [0..1]+ geometrySolid: GM_Solid [0..1]

«voidable»+ terrainIntersection: GM_MultiCurve [0..1]+ verticalGeometryReference3DBottom: ElevationReferenceValue [0..1]+ horizontalGeometryEstimatedAccuracy: Length [0..1]+ verticalGeometryEstimatedAccuracy: Length [0..1]


«voidable»+ horizontalGeometryReference: HorizontalGeometryReferenceValue [0..1]

no point referencing in 3D/*The horizontalGeometryReference attribute shal l not take the value entrancePoint, pointInsideBuilding or pointInsideCadastralParcel.*/inv: self.horizontalGeometryReference->excludesAll(Set{HorizontalGeometryReferenceValue::entrancePoint, HorizontalGeometryReferenceValue::pointInsideBuilding , HorizontalGeometryReferenceValue::pointInsideCadastralParcel})

oneGeometryToBeProvided/*Either the geometryMultiSurface or the geometrySolid attribute shal l be provided.*/inv: self.geometryMultiSurface->notEmpty() or self.geometrySolid->notEmpty()

Figure n° 29 : 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.



Figure n° 30: 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.

Figure n° 31: 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 - highestGroundPoint - lowestFloorAboveGround

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 - generalEave - lowestEave - 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.



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




«featureType»BuildingsBase::AbstractBuilding


«dataType»BuildingsBase::BuildingGeometry2D



«featureType»BuildingsBase::AbstractConstruction




Buildings - Base




+ geometry3DLoD1: BuildingGeometry3DLoD1 [0..1]+ geometry3DLoD2: BuildingGeometry3DLoD2 [0..1]+ geometry3DLoD3: BuildingGeometry3DLoD [0..1]+ geometry3DLoD4: BuildingGeometry3DLoD [0..1]

«voidable»+ geometry2D: BuildingGeometry2D [0..*]

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

MandatoryGeometryA BuildingPart must provide at least one geometry3D.


«voidable»+ horizontalGeometryReference: HorizontalGeometryReferenceValue [0..1]+ verticalGeometryReference3DTop: ElevationReferenceValue [0..1]

«dataType»BuildingGeometry3DLoD

+ geometryMultiSurface: GM_MultiSurface [0..1]+ geometrySolid: GM_Solid [0..1]

«voidable»+ terrainIntersection: GM_MultiCurve [0..1]+ verticalGeometryReference3DBottom: ElevationReferenceValue [0..1]+ horizontalGeometryEstimatedAccuracy: Length [0..1]+ verticalGeometryEstimatedAccuracy: Length [0..1]


«voidable»+ horizontalGeometryReference: HorizontalGeometryReferenceValue [0..1]

no point referencing in 3D/*The horizontalGeometryReference attribute shall not take the value entrancePoint, pointInsideBuilding or pointInsideCadastralParcel.*/inv: self.horizontalGeometryReference->excludesAll(Set{HorizontalGeometryReferenceValue::entrancePoint, HorizontalGeometryReferenceValue::pointInsideBuilding , HorizontalGeometryReferenceValue::pointInsideCadastralParcel})

oneGeometryToBeProvided/*Either the geometryMultiSurface or the geometrySolid attribute shall be provided.*/inv: self.geometryMultiSurface->notEmpty() or self.geometrySolid->notEmpty()+parts

«voidable»

0..*

Figure n° 36 – UML class diagram: Overview of the BuildingCore3D application schema

5.4.1.3. Consistency between spatial data sets It will be meaningful to use core3D data (when available) with INSPIRE themes taking also into account the vertical dimension, such as theme Elevation.

5.4.1.4. Identifier management Idem core 2D.

5.4.1.5. 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.4.1.6. Geometry representation NOTE 1: The Simple Feature requirement obviously does not apply for core 3D profile. 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).

Recommendation 6 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.4.1.7. Temporality representation Idem as in core 2D profile.



Feature catalogue name INSPIRE feature catalogue BuildingCore3D Scope BuildingCore3D Version number 2.9 Version date 2012-07-09 Definition source INSPIRE data specification BuildingCore3D


Type Package Stereotypes Section AbstractBuilding BuildingCore3D «featureType» 5.2.2.1.1 Building BuildingCore3D «featureType» 5.2.2.1.2 BuildingGeometry3DLoD BuildingCore3D «dataType» 5.2.2.2.1 BuildingGeometry3DLoD1 BuildingCore3D «dataType» 5.2.2.2.2 BuildingGeometry3DLoD2 BuildingCore3D «dataType» 5.2.2.2.3 BuildingPart BuildingCore3D «featureType» 5.2.2.1.3



AbstractBuilding (abstract) Name: Abstract Building Subtype of: AbstractBuilding Definition: Abstract feature type grouping the common properties of instanciable feature

types Building and BuildingPart. Description: In core 3D application schema, feature type AbstractBuilding includes both the

common semantic properties of Building and BuildingPart (by inheritance from feature type AbstractBuilding of base application schema) and the common geometric properties of Building and BuildingPart.

Status: Proposed Stereotypes: «featureType» Identifier: null Attribute: geometry2D



AbstractBuilding (abstract) Value type: BuildingGeometry2D Definition: Geometric representation of the building as 2D or 2,5D data. Description:

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

Multiplicity: 0..* Stereotypes: «voidable» Attribute: geometry3DLoD1

Value type: BuildingGeometry3DLoD1 Definition: Geometric representation of the building as 3D data at level of detail (LoD) 1, as

defined in City GML. LoD1 consists in the representation of the generalized outer boundary of the real world object by vertical lateral surfaces and horizontal base polygons.

Multiplicity: 0..1 Attribute: geometry3DLoD2

Value type: BuildingGeometry3DLoD2 Definition: Geometric representation of the building as 3D data at level of detail (LoD) 2, as

defined in City GML. LoD2 consists in the representation of the generalized outer boundary of the real world objectby 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).


Value type: BuildingGeometry3DLoD Definition: Geometric representation of the building as 3D data at level of detail (LoD) 3, as

defined in City GML. LoD3 consists in the representation of the detailed outer boundary (including protrusions, facade elements and window recesses) of the real world object as well as of the actual roof shape (including dormers, chimneys).


Value type: BuildingGeometry3DLoD Definition: Geometric representation of the building as 3D data at level of detail (LoD) 4, as

defined in City GML. LoD4 consists in the representation of the detailed outer boundary (including protrusions, facade elements, and window recesses) of the real world object as well as of the actual 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

5.4.2.1.2. Building

Building 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



Building erected on its site.

Status: Proposed Stereotypes: «featureType» Identifier: null 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» Constraint: GeometryWhenNoParts

Natural language:

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


BuildingPart 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 building part is homogeneous related to its physical, functional and

temporal aspects. EXAMPLE: A Building may be composed of two BuildingParts having different heights above ground.

Status: Proposed Stereotypes: «featureType» Identifier: null Constraint: MandatoryGeometry

Natural language:

A BuildingPart must provide at least one geometry3D.

5.4.2.2. Data types

5.4.2.2.1. BuildingGeometry3DLoD

BuildingGeometry3DLoD Name: Building Geometry3D LoD Definition: Data type grouping the different ways to provide the 3D geometry of a building or

building part. Status: Proposed Stereotypes: «dataType» Identifier: null Attribute: geometryMultiSurface

Value type: GM_MultiSurface Definition: Representation of the outer boundary of the real world object. The outer

boundary is represented 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



BuildingGeometry3DLoD

Attribute: geometrySolid

Value type: GM_Solid Definition: Representation of the generalized outer boundary of the real world object by a

solid. Multiplicity: 0..1 Attribute: terrainIntersection

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

Value type: ElevationReferenceValue Definition: Height level of the real world object 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» Obligation: Implementing Rule (requirement) Attribute: horizontalGeometryEstimatedAccuracy

Value type: Length Definition: The estimated absolute positional accuracy of the(X,Y) coordinates of the real

world object 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: verticalGeometryEstimatedAccuracy

Value type: Length Definition: The estimated absolute positional accuracy of the Z- coordinate of the real world

object 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.


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.4.2.2.2. BuildingGeometry3DLoD1

BuildingGeometry3DLoD1 Name: Building Geometry3D LoD1 Subtype of: BuildingGeometry3DLoD Definition: Data type grouping the different ways to provide the 3D geometry of a building or

building part, using LoD1 representation. Status: Proposed Stereotypes: «dataType» Identifier: null Attribute: horizontalGeometryReference

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» Obligation: Implementing Rule (requirement) Attribute: verticalGeometryReference3DTop

Value type: ElevationReferenceValue Definition: Height level of the real world object 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» Obligation: Implementing Rule (requirement) 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.4.2.2.3. BuildingGeometry3DLoD2

BuildingGeometry3DLoD2 Name: Building Geometry3D LoD2 Subtype of: BuildingGeometry3DLoD Definition: Data type grouping the different ways to provide the 3D geometry of a building or

building part, using LoD2 representation. Status: Proposed Stereotypes: «dataType» Identifier: null Attribute: horizontalGeometryReference

Value type: HorizontalGeometryReferenceValue Definition: Element of the real world object 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» Obligation: Implementing Rule (requirement)



BuildingGeometry3DLoD2

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})




AbstractBuilding (abstract) Package: INSPIRE Consolidated UML Model::Themes::Annex


Definition: Abstract feature type grouping the common properties of instanciable feature types Building and BuildingPart.

Description: NOTE: In base application schema, feature type AbstractBuilding includes only the common semantic properties of Building and BuildingPart.






ElevationReferenceValue Package: INSPIRE Consolidated UML Model::Themes::Annex


Definition: List of possible values for the element of the real world object that has been considered to capture its 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.4.2.3.4. GM_MultiCurve

GM_MultiCurve Package: INSPIRE Consolidated UML Model::Foundation Schemas::ISO TC211::ISO

19107:2003 Spatial Schema:: Geometry::Geometric aggregates [Include reference to the document that includes the package, e.g. INSPIRE data specification, ISO standard or the GCM]

5.4.2.3.5. GM_MultiSurface

GM_MultiSurface



GM_MultiSurface Package: INSPIRE Consolidated UML Model::Foundation Schemas::ISO TC211::ISO

19107:2003 Spatial Schema:: Geometry::Geometric aggregates [Include reference to the document that includes the package, e.g. INSPIRE data specification, ISO standard or the GCM]

5.4.2.3.6. GM_Solid

GM_Solid Package: INSPIRE Consolidated UML Model::Foundation Schemas::ISO TC211::ISO

19107:2003 Spatial Schema:: Geometry::Geometric primitive [Include reference to the document that includes the package, e.g. INSPIRE data specification, ISO standard or the GCM]


HorizontalGeometryReferenceValue Package: INSPIRE Consolidated UML Model::Themes::Annex


Definition: List of possible values for the element of the real world object that has been considered to capture its horizontal geometry.

Description: NOTE: The building component may be a BuildingPart or a BuildingUnit or a Room.

5.4.2.3.8. Length

Length Package: INSPIRE Consolidated UML Model::Foundation Schemas::ISO TC211::ISO

19103:2005 Schema Language::Basic Types::Derived::Units of Measure [Include reference to the document that includes the package, e.g. INSPIRE data specification, ISO standard or the GCM]

5.5 Application schema <extended 2D >

5.5.1 Description

5.5.1.1. Narrative description In the next version of data specification, a new way to present the model might be proposed in order to ensure that extended 2D profile is a formal extension of core 2D profile and/or to make model easier to understand. The content won’t be changed.

5.5.1.1.1. General approach Extended 2D profile is an illustrative profile. It 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. Extended2D profile is an extension of Core2D profile, i.e. it includes the same feature types and attributes and moreover contains additional feature types, attributes and associations.



Figure n° 37 : the instanciable feature types of extended2D profile

The extended 2D profile contains 5 instanciable feature types:

- Building - OtherConstruction - Installation - BuildingPart - BuildingUnit

• 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.

The common attributes of these instanciable feature types are factorised in various abstract feature types.

5.5.1.1.2. Building and BuildingPart These 2 feature types inherit of the attributes and constraints coming from core2D profile.



Figure n° 38: the attributes of AbstractBuilding (in extended2D profile, on the left) are exactly the same as the attributes of AbstractBuilding2D (in core2D profile, on the right)

Open issue 2: The current version of extended 2D profile is not a formal extension of core 2D, though the content at instance level of core 2D profile is included in extended 2D profile. To be solved for DS v3 (final draft).

Moreover, the extended profile offers, as additional properties, many attributes and association to CadastralParcel and to Address, that are feature types defined in annex I themes.

Core2D profile

Extended2D profile



Figure n° 39 : the additional attributes of Building and BuildingPart in extended 2D profile

Open issue 3: Data type for attribute document to be revised (DocumentCitation?

DocumentWithStatus? Document?)

5.5.1.1.3. 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.

Figure n° 40: The data type Document

Recommendation 7 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.

Connection to utility networks

Information about energy / heating

Physical description of building

Official information



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. NOTE 3: in case of an extension designed by the data producer, other data types defined in the consolidated INSPIRE UML model (see D2.10), such as DocumentCitation may be used. This may be relevant if more detailed information about the date (creation, publication, last update) is required.

5.5.1.1.4. Attribute roofType This attribute may take the following values:

Figure n° 41 : The possible values of code list RoofTypeValue

flatRoof monopitchRoof gabledRoof hippedRoof MansardRoof

halfHippedRoof coneRoof pyramidalBroachRoof copulaRoof

archRoof dualPentRoof sawToothRoof



pavilionRoof hyperbolicParabaloidalRoof Figure n° 42 : roof types (most illustrations from SIG 3D)

5.5.1.1.5. Attribute MaterialOfStructure

Figure n° 43 : The possible values of code list MaterialOfStructureValue

adobeBlockWalls concreteBlockMasonry earth firedBrickMasonry

informalConstructions massiveStoneMasonry mobileHomes mudWalls



precastConcrete

Tilt-upWalls reinforcedConcrete reinforcedMasonry rubleStoneMasonry

steel stoneMasonryBlock wood wood Figure n° 44: illustrations for material of structure

5.5.1.1.6. MaterialOfFacade

Figure n° 45 : The possible values of code list MaterialOfFacadeValue

adobe asbestos ceramicTiles composite



concrete glass limestone masonry

metal naturalStone vegetated wood

Figure n° 46: illustrations for material of structure

5.5.1.1.7. MaterialOfRoof

Figure n° 47 : The possible values of code list MaterialOfRoofValue

asbestos ceramicTiles clayTile composition

concreteTile corrugatedSheet glass hotMoppedAsphalt



metal reinforcedConcrete slate slate

thatch thatch vegetatedRoof woodShingles OrShakes

Figure n° 48: illustrations for material of structure

5.5.1.1.8. OtherConstruction This new feature type share most of (but not all) the attributes of Building and BuildingPart. It has a simpler geometric representation: GM_Primitive, i.e. it may be represented by a point, a line or surface. Its main attribute is the nature of the construction.

Figure n°49 : the properties of feature type OtherConstruction



acousticFence antenna chimney bridge bridge

cityWall crane monument monument monument

monument monument openAirPool protectiveStructure protectiveStructure

pylon retainingWall solarPanel substation tunnel Figure n° 50 : illustrations of other constructions

5.5.1.1.9. Installation This new feature type (as OtherConstruction) share most of (but not all) the attributes of Building and BuildingPart. It has a simple geometric representation: GM_Primitive, i.e. it may be represented by a point, a line or surface. Its main attribute is the nature of the construction. 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).



Figure n° 51 : the properties of feature type Installation

airConditioningUnit airDuct antenna antenna arcade

balcony chimney chimney cradle dormer



externalLift railing ramp solarPanel stairway

stairway stairway tower windTurbine windTurbine Figure n° 52 : illustrations for of installation nature

5.5.1.1.10. Feature type BuildingUnit 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. 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. On the opposite, the geometry of BuildingUnit is a voidable attribute. Feature type BuildingUnit shares with Building most of the attributes (see figure below) that may be found in cadastral or other official register, such as the current use, the official value, the connection to utility networks, …. Moreover, it also shares an association to CadastralParcel and to Address.



Figure n° 53 : the properties of feature type BuildingUnit



5.5.1.2. UML Overview class BuildingExtended2D



«featureType»AbstractBuildingExtended2D

«voidable»+ address: AddressRepresentation [0..*]+ connectionToElectricity: boolean [0..1]+ connectionToGas: boolean [0..1]+ connectionToSewage: boolean [0..1]+ connectionToWater: boolean [0..1]+ document: DocumentReferenceWithStatus [0..*]+ energyPerformance: EnergyPerformanceValue [0..1]+ floorDescription: FloorDescription [0..*]+ floorDistribution: FloorRange [1..*]+ heatingSource: HeatingSourceValue [0..*]+ heatingSystem: HeatingSystemValue [0..*]+ heightBelowGround: Length [0..1]+ materialOfFacade: MaterialOfFacadeValue [0..*]+ materialOfRoof: MaterialOfRoofValue [0..*]+ materialOfStructure: MaterialOfStructureValue [0..*]+ numberOfFloorsBelowGround: Integer [0..1]+ officialArea: OfficialArea [0..*]+ officialValue: OfficialValue [0..*]+ roofType: RoofTypeValue [0..*]

«featureType»BuildingUnit

+ externalReference: ExternalReference

«voidable»+ address: AddressRepresentation [0..*]+ connectionToElectricity: boolean [0..1]+ connectionToGas: boolean [0..1]+ connectionToSewage: boolean [0..1]+ connectionToWater: boolean [0..1]+ currentUse: CurrentUseValue [0..*]+ document: DocumentReferenceWithStatus [0..*]+ energyPerformance: EnergyPerformanceValue [0..*]+ heatingSource: HeatingSourceValue [0..*]+ heatingSystem: HeatingSystemValue [0..*]+ officialArea: OfficialArea [0..*]+ officialValue: OfficialValue [0..*]

«featureType»OtherConstructionNatureValue::

AbstractFeature


«voidable, li feCycleInfo»+ beginLifespanVersion: DateTime+ endLifespanVersion: DateTime [0..1]

constraints

{endLifespanVersion}


«voidable»+ buildingNature: BuildingNatureValue [0..*]+ currentUse: CurrentUse [0..*]+ numberOfBuildingUnits: Integer [0..1]+ numberOfDwellings: Integer [0..1]+ numberOfFloorsAboveGround: Integer [0..1]

«featureType»OtherConstruction

+ otherConstructionNature: OtherConstructionNatureValue«featureType»

Installation

+ instal lationNature: Instal lationNatureValue



AbstractBuildingUnitWith2DGeometry

«voidable»+ geometry2D: GM_Primitive

AbstractBuildingWith2DGeometry


AbstractConstructionWith2DGeometry

+ geometry2D: GM_Primitive

«featureType»Addresses::Address

constraints

{AddressPosition}{AddressCountry}{EndLifeSpanVersion}

«featureType»CadastralParcels::CadastralParcel

constraints

{geometryType}{areaValueUoM}{validTo}{endLifespanVersion}

A

Name: BuildingExtended2DAuthor: karjohVersion: 3.0Created: 2010-09-23 16:23:41Updated: 2012-04-26 11:50:58

0..*

+cadastralParcel«voidable»

0..*

+Instal lation 0..*

+address«voidable»

0..*

+address«voidable»

0..*

cadastralParcel«voidable»

0..*

+buildingUnit

0..*

+parts

0,2...*

Figure n° 54 – UML class diagram: Overview of the BuildingExtended2D application schema



class BuildingExtended2DCodeList1

«codeList»MaterialOfFacadeValue

+ adobe+ asbestos+ ceramicTiles+ composite+ concrete+ glass+ limestone+ masonry+ metal+ naturalStone+ vegetated+ wood

«codeList»MaterialOfRoofValue

+ asbestos+ ceramicTile+ clayTile+ composition+ concreteTile+ corrugatedSheet+ glass+ hotMoppedAsphal t+ metal+ reinforcedConcrete+ slate+ thatch+ vegetatedGreenRoof+ woodShinglesOrShakes

tags

extensiblity = anyvocabulary = http://inspire.ec.europa.eu/codeList/MaterialOfRoofValue

«codeList»MaterialOfStructureValue

+ adobeBlockWalls+ concreteBlockMasonry+ earth+ firedBrickMasonry+ informalConstructions+ massiveStoneMasonry+ mobileHomes+ mudWalls+ precastConcreteTilt-upWalls+ reinforcedConcrete+ reinforcedMasonry+ rubleStoneMasonry+ steel+ stoneMasonryBlock+ wood

tags

extensibil ity = anyvocabulary = http://inspire.ec.europa.eu/codeList/MaterialOfStructureValue

«codeList»OfficialAreaReferenceValue

tags

extensibil ity = vocabulary =

«codeList»RoofTypeValue

+ archRoof+ conicalRoof+ domedRoof+ dualPentRoof+ flatRoof+ gabledRoof+ halfHippedRoof+ hippedRoof+ hyperbolicParabaloidalRoof+ mansardRoof+ monopitchRoof+ pavil ionRoof+ pyramidalBroachRoof+ sawToothRoof

tags

extensibil ity = anyvocabulary = http://inspire.ec.europa.eu/codeList/RoofTypeValue

Name: BuildingExtended2DCodeList1Author: karjohVersion: 3.0Created: 2011-01-17 10:27:54Updated: 2012-04-26 11:51:06

«codeList»HeatingSystemValue

+ centralHeating+ districtHeating+ electricRaditors+ heatPump+ portableGasHeating+ solarHeating+ stove

tags

extensiblity = anyvocabulary = http://inspire.ec.europa.eu/codeList/HeatingSystemValue

«codeList»HeatingSourceValue

+ biogas+ electricity+ liquidFuels+ naturalGas+ solidFuels+ straw+ warmWaterOrStream

tags

extensiblity = anyvocabulary = http://inspire.ec.europa.eu/codeList/HeatingSourceValue

«codeList»CLGE_OfficialAreaReferenceValue

+ constructedArea+ externalArea+ internalArea+ internalPrimaryArea+ internalOtherArea+ internalResidualArea+ internalServiceArea

tags

extensibil ity = nonevocabulary = http://inspire.ec.europa.eu/codeList/OfficialAreaReferenceValue

«codeList»OtherStandardOfficialAreaReferenceValue

tags

extensibil ity = anyvocabulary =

{complete{complete

Figure n° 55 – UML class diagram: Overview of the BuildingExtended2DCodeList1 application schema



class BuildingExtended2DCodeList2

«codeList»InstallationNatureValue

+ airConditioningUnit+ airDuct+ antenna+ arcade+ balcony+ chimney+ cradle+ dormer+ externalLift+ rai ling+ ramp+ solarPanel+ stairway+ tower+ windTurbine

tags

extensibi lity = anyvocabulary = http://inspire.ec.europa.eu/codeList/InstallationNatureValue

«codeList»OtherConstructionNatureValue

+ acousticFence+ antenna+ bridge+ chimney+ cityWall+ crane+ monument+ openAirPool+ protectiveStructure+ pylon+ retainingWall+ solarPanel+ substation+ tunnel

tags

extensibili ty = anyvocabulary = http://inspire.ec.europa.eu/codeList/OtherConstructionNatureValue

«codeList»CurrencyValue

+ ALL+ BAM+ BGN+ BYR+ CHE+ CHF+ CZK+ DKK+ EUR+ GBP+ HRK+ HUF+ ISK+ LTL+ LVL+ MDL+ MKD+ NOK+ PLN+ RON+ RSD+ RUB+ SEK+ TRY+ UAH

tags

codeList = http://inspire-registry.j rc.ec.europa.eu/clr/CurrencyValueextensibili ty = anyvocabulary = http://inspire.ec.europa.eu/codeList/CurrencyValue

«codeList»OfficialValueReferenceValue

+ rental Income+ transactionPriceSimple+ transactionPriceMedium+ transactionPriceFul l

tags

extensibi li ty = anyvocabulary = http://inspire.ec.europa.eu/codeList/OfficialValueReferenceValue

«codeList»EnergyPerformanceValue

+ A+ B+ C+ D+ E+ F+ G

tags

codeList = http://inspire-registry.jrc.ec.europa.eu/clr/EnergyPerformanceValueextensibi lity = nonevocabulary = http://inspire.ec.europa.eu/codeList/EnergyPerformanceValue

Name: Bui ldingExtended2DCodeList2Author: karjohVersion: 3.0Created: 2012-04-19 10:05:28Updated: 2012-04-26 11:51:13

Figure n° 56 – UML class diagram: Overview of the BuildingExtended2DCodeList2 application schema



class BuildingExtended2DDataTypes

«dataType»OfficialArea

+ value: Area

«voidable»+ officialAreaReference: OfficialAreaReferenceValue+ heightParameter: Length [0..1] = 2.10 m

«dataType»EnergyPerformance

+ energyPerformanceValue: EnergyPerformanceValue

«voidable»+ dateOfAssessment: DateTime

«dataType»OfficialValue

+ currency: CurrencyValue+ value: Integer

«voidable»+ valuationDate: DateTime+ officialValueReference: OfficialValueReferenceValue+ referencePercentage: Integer

Name: BuildingExtended2DDataTypesAuthor: karjohVersion: 3.0Created: 2012-04-13 14:30:20Updated: 2012-04-19 23:35:50

«dataType»FloorRange

+ lowestFloor: float+ highestFloor: float

«dataType»FloorDescription

+ floorRange: FloorRange [1..*]

«voidable»+ document: DocumentReferenceWithStatus [0..*]+ floorArea: Area+ currentUse: CurrentUseValue [1..*]+ height: Length+ numberOfDwell ings: Integer+ areaOfOpenings: Area

Figure n° 57 – UML class diagram: Overview of the BuildingExtended2DDataTypes application schema

5.5.1.3. Consistency between spatial data sets Idem core 2D.


5.5.1.5. Modelling of object references Idem core 2D.

5.5.1.6. Geometry representation Idem core 2D.

5.5.1.7. Temporality representation Idem core 2D.




Table 3 - Feature catalogue metadata

Feature catalogue name INSPIRE feature catalogue BuildingExtended2D Scope BuildingExtended2D Version number 2.9 Version date 2012-04-20 Definition source INSPIRE data specification BuildingExtended2D

Table 4 - Types defined in the feature catalogue

Type Package Stereotypes Section AbstractBuilding BuildingExtended2D «featureType» 5.2.2.1.1 AbstractBuildingExtended2D BuildingExtended2D «featureType» 5.2.2.1.2 AbstractConstruction BuildingExtended2D «featureType» 5.2.2.1.3 Building BuildingExtended2D «featureType» 5.2.2.1.4 BuildingPart BuildingExtended2D «featureType» 5.2.2.1.5 BuildingUnit BuildingExtended2D «featureType» 5.2.2.1.6 CLGE_OfficialAreaReferenceValue BuildingExtended2D «codeList» 5.2.2.3.1 CurrencyValue BuildingExtended2D «codeList» 5.2.2.3.2 EnergyPerformance BuildingExtended2D «dataType» 5.2.2.2.1 EnergyPerformanceValue BuildingExtended2D «codeList» 5.2.2.3.3 FloorDescription BuildingExtended2D «dataType» 5.2.2.2.2 FloorRange BuildingExtended2D «dataType» 5.2.2.2.3 HeatingSourceValue BuildingExtended2D «codeList» 5.2.2.3.4 HeatingSystemValue BuildingExtended2D «codeList» 5.2.2.3.5 Installation BuildingExtended2D «featureType» 5.2.2.1.7 InstallationNatureValue BuildingExtended2D «codeList» 5.2.2.3.6 MaterialOfFacadeValue BuildingExtended2D «codeList» 5.2.2.3.7 MaterialOfRoofValue BuildingExtended2D «codeList» 5.2.2.3.8 MaterialOfStructureValue BuildingExtended2D «codeList» 5.2.2.3.9 OfficialArea BuildingExtended2D «dataType» 5.2.2.2.4 OfficialAreaReferenceValue BuildingExtended2D «codeList» 5.2.2.3.10 OfficialValue BuildingExtended2D «dataType» 5.2.2.2.5 OfficialValueReferenceValue BuildingExtended2D «codeList» 5.2.2.3.11 OtherConstruction BuildingExtended2D «featureType» 5.2.2.1.8 OtherConstructionNatureValue BuildingExtended2D «codeList» 5.2.2.3.12 OtherStandardOfficialAreaReferenceValue BuildingExtended2D «codeList» 5.2.2.3.13 RoofTypeValue BuildingExtended2D «codeList» 5.2.2.3.14



AbstractBuilding (abstract) Name: Abstract Building Subtype of: AbstractBuildingWith2DGeometry Definition: Abstract feature type grouping the semantic common properties of instanciable

feature types Building and BuildingPart. Status: Proposed Stereotypes: «featureType» Identifier: null



AbstractBuilding (abstract)

Attribute: buildingNature

Value type: BuildingNatureValue Definition: Characteristics of the building that makes it generally of interest for mapping

purposes. Description: NOTE 1: The characteristic may be related to the physical aspect and/or to the

function of the building. Multiplicity: 0..* Stereotypes: «voidable» Obligation: Technical Guidance (recommendation)

Attribute: currentUse

Value type: CurrentUse Definition: Activity hosted by the real world object. Description: NOTE: This attribute addresses mainly the buildings hosting human activities. Multiplicity: 0..* Stereotypes: «voidable»

Attribute: numberOfBuildingUnits



Description: Building Unit is a feature type aimed at subdividing a whole building or a building part into smaller parts that are treated as separate entities in daily life.A BuildingUnit is homogeneous, regarding management aspects. EXAMPLES: It may be e.g. an apartment in a multi-owner building, a terraced house, or a shop inside a shopping arcade. NOTE: 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.

Multiplicity: 0..1 Stereotypes: «voidable»

Attribute: numberOfDwellings

Value type: Integer Definition: Number of dwellings in the real world object. Multiplicity: 0..1 Stereotypes: «voidable»

Attribute: numberOfFloorsAboveGround


Association role: cadastralParcel

Value type: CadastralParcel Definition: The cadastral parcel(s) to which the building or building part is officially related. Multiplicity: 0..* Stereotypes: «voidable»

Association role: address

Value type: Address



AbstractBuilding (abstract) Definition: The address(es) of the building or building part. Description: This association provides link to the whole address model of theme Address,

with the current address, its life-cycle and the life-cycle of each of its component. Multiplicity: 0..* Stereotypes: «voidable»

5.5.2.1.2. AbstractBuildingExtended2D

AbstractBuildingExtended2D (abstract) Name: Abstract Building Extended2D Subtype of: AbstractBuilding Definition: Abstract feature type grouping the additional properties of Building and Building

Part. Description: The additonal properties are those that are not already included in the core2D

profile. Status: Proposed Stereotypes: «featureType» Identifier: null Attribute: connectionToElectricity

Value type: boolean Definition: An indication if the building or building part is connected or not to the public

electricity network. Multiplicity: 0..1 Stereotypes: «voidable» Obligation: null

Attribute: connectionToGas

Value type: boolean Definition: An indication if the building or building part is connected or not to the public gas

network. Multiplicity: 0..1 Stereotypes: «voidable» Obligation: null

Attribute: connectionToSewage


sewage network. Multiplicity: 0..1 Stereotypes: «voidable» Obligation: null

Attribute: connectionToWater

Value type: boolean Definition: An indication if the building or building part connected or not to the public water


Attribute: document

Value type: DocumentReferenceWithStatus Definition: Any document providing information about the building or building part.



AbstractBuildingExtended2D (abstract) 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

Value type: EnergyPerformanceValue Definition: The energy performance of the building or building part. Description: 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» Obligation: Technical Guidance (recommendation)

Attribute: floorDescription

Value type: FloorDescription Definition: The description of a given range of building floors. Multiplicity: 0..* Stereotypes: «voidable»

Attribute: floorDistribution

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: heatingSource

Value type: HeatingSourceValue Definition: The source of energy used for the heating Description: EXAMPLES: electricity, natural gas Multiplicity: 0..* Stereotypes: «voidable» Obligation: Technical Guidance (recommendation)

Attribute: heatingSystem

Value type: HeatingSystemValue Definition: The system of heating Description: EXAMPLES : stove, central heting, heat pump Multiplicity: 0..* Stereotypes: «voidable» Obligation: Technical Guidance (recommendation)

Attribute: heightBelowGround

Value type: Length Definition: Height below ground of the building or building part. Multiplicity: 0..1 Stereotypes: «voidable»

Attribute: materialOfFacade

Value type: MaterialOfFacadeValue Definition: Material(s) of the building or building part facade.



AbstractBuildingExtended2D (abstract) Multiplicity: 0..* Stereotypes: «voidable» Obligation: Technical Guidance (recommendation)

Attribute: materialOfRoof

Value type: MaterialOfRoofValue Definition: Material(s) of the building or building part roof. Multiplicity: 0..* Stereotypes: «voidable» Obligation: Technical Guidance (recommendation)

Attribute: materialOfStructure

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» Obligation: Technical Guidance (recommendation)

Attribute: numberOfFloorsBelowGround

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: officialArea

Value type: OfficialArea Definition: The area of the building or building part as registered in an official information

system Multiplicity: 0..* Stereotypes: «voidable»

Attribute: officialValue

Value type: OfficialValue Definition: The value of the buildingor building part as registered in official information


Attribute: roofType

Value type: RoofTypeValue Definition: The shape of the roof. Multiplicity: 0..* Stereotypes: «voidable» Obligation: Technical Guidance (recommendation)

Attribute: address

Value type: AddressRepresentation Definition: The address(es) of the building or building part. Description: This attribute provides the current address(es) of the building in the structured

data type defined in theme Address.



AbstractBuildingExtended2D (abstract) Multiplicity: 0..* Stereotypes: «voidable»

Association role: Installation

Value type: Installation Definition: The installation(s) serving the building or building part. Multiplicity: 0..*

Association role: buildingUnit

Value type: BuildingUnit Definition: The building unit(s) belonging to the building or building part. Multiplicity: 0..*


AbstractConstruction (abstract) Name: Abstract Construction Subtype of: AbstractFeature Definition: Abstract feature type grouping common properties of instanciable feature types

Building, BuildingPart and OtherConstruction. Status: Proposed Stereotypes: «featureType» Identifier: null Attribute: conditionOfConstruction

Value type: ConditionOfConstructionValue Definition: Status of the construction related to its real world life-cycle. Multiplicity: 1 Stereotypes: «voidable» Obligation: Technical Guidance (recommendation)

Attribute: dateOfConstruction

Value type: DateOfEvent Definition: NOTE: this attribute has multiplicity 0..1 because =in case the construction is

only under project, the date of construction may not exist yet. Multiplicity: 0..1 Stereotypes: «voidable»

Attribute: dateOfDemolition

Value type: DateOfEvent Definition: Date of demolition of the construction,if any. -- Note -- It is not mandatory to give

neither the time nor the day or the month. Multiplicity: 0..1 Stereotypes: «voidable»

Attribute: dateOfRenovation

Value type: DateOfEvent Definition: Date of last major renovation of the construction, if any. Multiplicity: 0..1 Stereotypes: «voidable»

Attribute: elevation

Value type: Elevation



AbstractConstruction (abstract) Definition: Vertical-constrained dimensional property of the construction consisting of an

absolute measure referenced to a well-defined surface which is commonly taken as origin (geoid, water level, etc.)

Description: Source: adapted from definition given by TWG EL Multiplicity: 0..* Stereotypes: «voidable»

Attribute: externalReference


related to the construction. Description: EXAMPLE 1: reference to another spatial data set containing another view on

constructions; the externalReference may be used for instance to ensure consistency between 2D and 3D representations of the same constructions EXAMPLE 2: reference to cadastral or dwelling register. The reference to this register may enable to find legal information related to the construction, 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 construction physical and temporal aspects.


Attribute: heightAboveGround

Value type: HeightAboveGround Definition: Height above ground of the construction Description: NOTE: height above ground may be defined as the difference between elevation



Attribute: name

Value type: GeographicalName Definition: Name of the construction. Description: Examples: Big Ben, Eiffel Tower Multiplicity: 0..* Stereotypes: «voidable»

5.5.2.1.4. Building

Building Name: Building Subtype of: AbstractBuildingExtended2D Definition: A Building is an enclosed construction above and/or underground, used or



Value type: BuildingPart Definition: The building parts composing the Building.



Building Description: A building may be a simple building (with no BuildingPart) or a composed

building (with several BuildingParts). Multiplicity: 0,2...*


BuildingPart Name: Building Part Subtype of: AbstractBuildingExtended2D Definition: A BuildingPart is a sub-division of a Building that might be considered itself as a


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.


5.5.2.1.6. BuildingUnit

BuildingUnit Name: Building Unit Subtype of: AbstractBuildingUnitWith2DGeometry 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: BuildingUnit is a feature type aimed at subdividing a whole building or a building part into smaller parts that are treated as seperate entities in daily life. A BuildingUnit is homogeneous, regarding management aspects. EXAMPLE: It may be e.g. an apartment in a condominium, a terraced house, or a shop inside a shopping arcade. NOTE: 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.

Status: Proposed Stereotypes: «featureType» Identifier: null Attribute: address

Value type: AddressRepresentation Definition: The address(es) of the building unit. Description: This attribute provides the current address(es) of the building unit in the

structured data type defined in themeAddress. Multiplicity: 0..* Stereotypes: «voidable»

Attribute: connectionToElectricity

Value type: boolean Definition: An indication if the building unit is connected or not to the public electricity





BuildingUnit Value type: boolean Definition: An indication if the building unit is connected or not to the public gas network. Multiplicity: 0..1 Stereotypes: «voidable» Obligation: null


Value type: boolean Definition: An indication if the building unit is connected or not to the public sewage



Value type: boolean Definition: An indication if the building unit is connected or not to the public water network. Multiplicity: 0..1 Stereotypes: «voidable» Obligation: null


Value type: CurrentUseValue Definition: Activity hosted by the building unit. Multiplicity: 0..* Stereotypes: «voidable» Obligation: Technical Guidance (recommendation)

Attribute: document

Value type: DocumentReferenceWithStatus Definition: Any document providing information about the building unit. Description: EXAMPLES:A photo or a sketch of interior, the energy performance assessment. Multiplicity: 0..* Stereotypes: «voidable»


Value type: EnergyPerformanceValue Definition: The energy performance of the building unit. Description: The energy performance is required by the Energy Performance of Building

Directive for the new buildings being rent or sold. Multiplicity: 0..* Stereotypes: «voidable» Obligation: Technical Guidance (recommendation)



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



BuildingUnit


Value type: HeatingSourceValue Definition: The source of energy used for the heating. Description: EXAMPLES: electricity, natural gas Multiplicity: 0..* Stereotypes: «voidable» Obligation: Technical Guidance (recommendation)




Value type: OfficialArea Definition: The area of the building unit as registered in an official information system. Multiplicity: 0..* Stereotypes: «voidable»


Value type: OfficialValue Definition: The value of the building as registered in official information system. Multiplicity: 0..* Stereotypes: «voidable»

Association role: address

Value type: Address Description: This association provides link to the whole address model of theme Address,

with the current address, its life-cycle and the life-cycle of each of its components.


Association role:

Value type: CadastralParcel Definition: The cadastral parcel(s) to which the building unit is officially related. Multiplicity: 0..* Stereotypes: «voidable»

5.5.2.1.7. Installation

Installation Name: Installation Subtype of: AbstractConstructionWith2DGeometry Definition: An external construction (of small size) or an external device serving the building

or building part. Description: EXAMPLES: stairway, solar panel, external lift Status: Proposed Stereotypes: «featureType» Identifier: null



Installation

Attribute: installationNature

Value type: InstallationNatureValue Definition: A description of the real world object that represents its intended nature or

current function. Multiplicity: 1 Obligation: Technical Guidance (recommendation)

5.5.2.1.8. OtherConstruction

OtherConstruction Name: Other Construction Subtype of: AbstractConstructionWith2DGeometry 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.

Status: Proposed Stereotypes: «featureType» Identifier: null Attribute: otherConstructionNature

Value type: OtherConstructionNatureValue Definition: A description of the feature that represents its intended nature or current function

and which differentiates it from that of a Building. Multiplicity: 1 Obligation: Technical Guidance (recommendation)

5.5.2.2. Data types

5.5.2.2.1. EnergyPerformance

EnergyPerformance Name: Energy Performance Definition: This data type describes the energy performance of the building or building unit. Status: Proposed Stereotypes: «dataType» Identifier: null Attribute: dateOfAssessment

Value type: DateTime Definition: The date when the energy performance of the building or building unit was

assessed. Multiplicity: 1 Stereotypes: «voidable»

Attribute: energyPerformanceValue

Value type: EnergyPerformanceValue Definition: The class of energy performance of the building or building unit. Multiplicity: 1 Obligation: Technical Guidance (recommendation)



5.5.2.2.2. FloorDescription

FloorDescription Name: Floor Description Definition: This data type gathers the main characteristics of the floor of a building. Description: The common characteristics are the ones coming from the use cases considered

by this data specification. Status: Proposed Stereotypes: «dataType» Identifier: null Attribute: document

Value type: DocumentReferenceWithStatus 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: floorRange

Value type: FloorRange Definition: Therange of floors having common characteristics. Description: NOTE:Many 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: floorArea

Value type: Area Definition: The ground area of the floor. Multiplicity: 1 Stereotypes: «voidable»


Value type: CurrentUseValue Definition: The current use(s) of the floor. Multiplicity: 1..* Stereotypes: «voidable» Obligation: Technical Guidance (recommendation)

Attribute: height

Value type: Length Definition: The height of the floor. Multiplicity: 1 Stereotypes: «voidable»


Value type: Integer Definition: The number of dwellings of the floor. Multiplicity: 1 Stereotypes: «voidable»

Attribute: areaOfOpenings

Value type: Area



FloorDescription 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 help to assess the vulnerability of buildings to

earthquakes. Multiplicity: 1 Stereotypes: «voidable»

5.5.2.2.3. FloorRange

FloorRange Name: Floor Range 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.

Status: Proposed Stereotypes: «dataType» Identifier: null Attribute: lowestFloor

Value type: float 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 Obligation: null

Attribute: highestFloor

Value type: float 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 Obligation: null

5.5.2.2.4. OfficialArea

OfficialArea Name: Official Area Definition: This data types includes the official area of the building and information about

the exact meaning of this area. Status: Proposed Stereotypes: «dataType» Identifier: null Attribute: 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 or by using another standard. EXAMPLES: internal area, external area



OfficialArea Multiplicity: 1 Stereotypes: «voidable» Obligation: Technical Guidance (recommendation)

Attribute: value

Value type: Area Definition: The value of the official area Multiplicity: 1

Attribute: 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.


Constraint: valueUoM

Natural language:

Unit of value must be square meter.

OCL: inv: self.value.uom.uomSymbol='m2'

5.5.2.2.5. OfficialValue

OfficialValue Name: Official Value Definition: The official value is provided by a value and its currency. 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.

Status: Proposed Stereotypes: «dataType» Identifier: null Attribute: value

Value type: Integer Definition: The official value of the building or building unit. Multiplicity: 1

Attribute: officialValueReference

Value type: OfficialValueReferenceValue Definition: The reference market price that the official value aims to assess. Description: EXAMPLE: rental income Multiplicity: 1 Stereotypes: «voidable» Obligation: Technical Guidance (recommendation)

Attribute: referencePercentage

Value type: Integer Definition: The percentage of the market price that the official value aims to assess. Multiplicity: 1 Stereotypes: «voidable»

Attribute: currency



OfficialValue Value type: CurrencyValue Definition: The currency in which the official value is provided. Multiplicity: 1 Obligation: Technical Guidance (recommendation)

Attribute: 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»

5.5.2.3. Code lists

5.5.2.3.1. CLGE_OfficialAreaReferenceValue

CLGE_OfficialAreaReferenceValue Name: CLGE_ Official Area Reference Subtype of: OfficialAreaReferenceValue Definition: The list of possible values for the reference of official area, as defined in the

CLGE measurement code for the floor area of buildings. Status: Proposed Stereotypes: «codeList» Extensibility: none Identifier: http://inspire.ec.europa.eu/codeList/OfficialAreaReferenceValue Value: constructedArea

Definition: Constructed area is the difference between the external area and the internal area of the building or building unit.

Description: NOTE: Constructed area is mainly used as technical data.

Value: externalArea

Name: external area Definition: External area is the area within the outer perimeter boundary of a building or

building unit, including any outer cladding, measured at floor level. Description: NOTE: External area is mainly used for spatial planning purpose.

Value: internalArea

Name: internal area Definition: Internal area is the area within the interior perimeter of a building or building unit,

measured above skirting-board level. Description: Internal area is mainly used as reference unit of measure in valuation, property

transaction, renting and building management.

Value: internalPrimaryArea

Definition: Internal primary area is the sum of all floor areas with a heightroom superior or equal to heightParameter and that are associated with the principal uses of the building.

Description: Internal primary area includes: - in housing: living areas (dining rooms, bedrooms), toilet, areas (bathrooms, lavatories), interior space and passageways, storage areas, … - in offices: work areas, meeting rooms, annexes, recreational areas, toilets, interior space and passageways,…..

Value: internalOtherArea



CLGE_OfficialAreaReferenceValue Name: internal other area Definition: Internal other area is the sum of all floor areas with a heightroom <

heightParameter and that are associated with the main uses of the building. Description: Internal other areas includes in particular garages, passageways and non-

enclosed covered area (canopies, car-ports, ...).

Value: internalResidualArea

Name: internal residual area Definition: Internal residual area is the sum of all floor areas regardless of height that are

not consistent with the principaluse of the building. Description: Internal residual area includes in particular underground storage and archive

rooms, cellars, parking garage, balconies, upper floor terraces, loggias.

Value: internalServiceArea

Name: internal service area Definition: Internal service area is the sum of all floor areas used for building services,

irrespective of their height or occupation. Description: Internal service area includes in particular lift shafts, stairwells, access ramps,

maintenance and technical areas serving the building.

5.5.2.3.2. CurrencyValue

CurrencyValue Name: Currency Definition: Code list for possible values of attribute currency Description: NOTE: include currencies from all European countries, including that are not

Member States of European Union. SOURCE: values are extracted from ISO 4217 standard.

Status: Proposed Stereotypes: «codeList» Extensibility: any Identifier: http://inspire.ec.europa.eu/codeList/CurrencyValue Value: ALL

Definition: Lek (in Albania)

Value: BAM

Definition: Convertible Mark (in Bosnia & Herzegovina)

Value: BGN

Definition: Bulgarian Lev (in Bulgaria)

Value: BYR

Definition: Belarussian Ruble (in Belarus)

Value: CHE

Definition: WIR Euro (in Switzerland). Description: NOTE: "WIR" is both an abbreviation of "Wirtschaftsring Genossenschaft" and

the word for "we" in German, reminding participants that the economic circle is also a community.

Value: CHF

Definition: Swiss Franc (in Switzerland and Liechtenstein)

Value: CZK

Definition: Czech Koruna (in Czech Republic)



CurrencyValue

Value: DKK

Definition: Danish Krone (in Denmark)

Value: EUR

Definition: euro

Value: GBP

Definition: Pound Sterling (in United Kingdom)

Value: HRK

Definition: Croatian Kuna (in Croatia)

Value: HUF

Definition: Forint (in Hungary)

Value: ISK

Definition: Iceland Krona (in Iceland)

Value: LTL

Definition: Lithuanian Litas (in Lithuania)

Value: LVL

Definition: Latvian Lats (in Latvia)

Value: MDL

Definition: Moldovan Leu (in Republic of Moldavia)

Value: MKD

Definition: Denar (in the former yugoslav republic of Macedonia)

Value: NOK

Definition: Norwegian Krone (in Norway)

Value: PLN

Definition: Zloty (in Poland)

Value: RON

Definition: Leu (in Romania)

Value: RSD

Definition: Serbian Dinar (in Serbia)

Value: RUB

Definition: Russian Ruble (in Russian federation)

Value: SEK

Definition: Swedish Krona (in Sweden)

Value: TRY

Definition: Turkish Lira (in Turkey)

Value: UAH

Definition: Hryvnia (in Ukraine)



5.5.2.3.3. EnergyPerformanceValue

EnergyPerformanceValue Name: Energy Performance Definition: Code list for possible values of energy performance of a building. Status: Proposed Stereotypes: «codeList» Extensibility: none Identifier: http://inspire.ec.europa.eu/codeList/EnergyPerformanceValue Value: A

Definition: First class according to the energy performance of the building (i.e. the most efficient buildings for energy performance).

Value: B

Definition: Second class according to the energy performance of the building.

Value: C

Definition: Third class according to the energy performance of the building.

Value: D

Definition: Fourth class according to the energy performance of the building.

Value: E

Definition: Fifth class according to the energy performance of the building.

Value: F

Definition: Sixth class according to the energy performance of the building.

Value: G

Definition: Seventh and last class according to the energy performance of the building (i.e. the most efficient buildings for energy performance).

5.5.2.3.4. HeatingSourceValue

HeatingSourceValue Name: Heating Source Status: Proposed Stereotypes: «codeList» Extensibility: any Identifier: http://inspire.ec.europa.eu/codeList/HeatingSourceValue Value: biogas

Name: biogas Definition: The heating source is biogas. Description: Biogas may come from a local biogas plant or more rarely be produced on a

household scale.

Value: electricity

Name: electricity Definition: The heating source is electricity distributed from power plant.

Value: liquidFuels

Name: liquid fuels Definition: The heating source is solid fuel. Description: Solid fuels include wood, charcoal, peat, coal, tablets and pellets made from

wood.



HeatingSourceValue

Value: naturalGas

Name: natural gas Definition: The heating source is fossil gas distributed by pipeline.

Value: solidFuels

Name: solid fuels Definition: The heating source is solid fuel. Description: Solid fuels include wood, charcoal, peat, coal, tablets and pellets made from

wood.

Value: straw

Name: straw Definition: The heating source is solid biofuels from straw and agricultural waste.

Value: warmWaterOrStream

Name: warm water or stream Definition: The heating source used by the building or building unit is hot water or stream. Description: Warm water or stream is generally distributed by central district heating.

5.5.2.3.5. HeatingSystemValue

HeatingSystemValue Name: Heating System Status: Proposed Stereotypes: «codeList» Extensibility: any Identifier: http://inspire.ec.europa.eu/codeList/HeatingSystemValue Value: centralHeating

Name: central heating Definition: Central heating system performed at building or at building unit level.

Value: districtHeating

Name: district heating Definition: Central heating system, based on district heating. Description: The public heat network is connected to the central heating of the building by a

heat exchanger. The warm water or steam used in the district heating system is not mixed with the water of the central heating system in the building.

Value: electricRaditors

Name: electric radiators Definition: Heating is performed by electric radiators. Description: Electric radiators could be single portable units or an integrated installation of the

building.

Value: heatPump

Name: heat pump Definition: The heating is performed by a heat pump that transfers thermal energy from an

air source or geothermal source. Description: The device is sometimes connected to the central heating system in the building.

Value: portableGasHeating

Name: portable gas heating Definition: Heating is performed by a portable device using liquefied petroleum gas.



HeatingSystemValue

Value: solarHeating

Name: solar heating Definition: The heating is performed by a Solar collector heating the air or liquid based

heating system. Description: This value is usually not used for solar cells producing electricity.

Value: stove

Name: stove Definition: Heating performed by a stove. Description: Stove includes all kinds of devices designed to burn solid fuel, traditionally wood

etc. including masonry fireplaces, tile stoves and fire stoves made of cast iron.

5.5.2.3.6. InstallationNatureValue

InstallationNatureValue Name: Installation Nature Status: Proposed Stereotypes: «codeList» Extensibility: any Identifier: http://inspire.ec.europa.eu/codeList/InstallationNatureValue Value: airConditioningUnit

Name: airConditioningUnit Definition: An air conditioning unit or air conditioner is a home appliance, system, or

mechanism designed to dehumidify and extract heat from an area. Description: Only the external air conditioning units located outside the building shall be

considered as Installation.

Value: airDuct

Definition: Ducts for incoming (fresh) and outgoing (stale) air.

Value: antenna

Name: antenna Definition: A transducer designed to transmit or receive electromagnetic waves (includes

radio and television masts, radar towers and satellite telecommunications). Description: Only antennas attached to buildings shall be considered as Installation.

Self-standing antennas shall be considered as OtherConstruction

Value: arcade

Name: arcade Definition: An arcade is a covered passage, usually with shops on one or both sides.

Value: balcony

Name: balcony Definition: A balcony is a upper accessible platform within a storey, not fully enclosed by

wall(s).

Value: chimney

Name: chimney Definition: A vertical structure containing a passage or flue for discharging smoke and

gases of combustion. Description: Only chimneys attached to buildings shall be considered as Installation.

Self-standing chimneys shall be considered as OtherConstruction.

Value: cradle



InstallationNatureValue Definition: A small suspended platform that can be moved up and down the outside of a

high building, used by people cleaning or maintaining windows or facades, etc. Description: The cradles that are permanently installed in a building and may be used for

emergency evacuation are of interest for INSPIRE.

Value: dormer

Name: dormer Definition: A dormer is a structural element of a building that protrudes from the plane of a

sloping roof surface. Dormers are used, either in original construction or as later additions, to create usable space in the roof of a building by adding headroom and usually also by enabling addition of windows.

Value: externalLift

Name: externalLift Definition: Lift moving along the outside of a building.

Value: railing

Name: railing Definition: A handrail is a rail that is designed to be grasped by the hand so as to provide

stability or support.

Value: ramp

Name: ramp Definition: A (wheelchair) ramp is an inclined plane installed in addition to or instead of

stairs.

Value: solarPanel

Name: solarPanel Definition: A solar panel is a packaged, connected assembly of solar cells, also known as

photovoltaic cells. The solar panel can be used as a component of a larger photovoltaic system to generate and supply electricity in commercial and residential applications.

Description: Only the solar panels attached to the building should be considered as installations. The self-standing solar panels should be classified under OtherConstruction.

Value: stairway

Name: stairway Definition: Stairway is a construction designed to bridge a large vertical distance by dividing

it into smaller vertical distances, called steps. Stairways may be straight, round, or may consist of two or more straight pieces connected at angles.

Value: tower

Name: tower Definition: A relatively tall, narrow structure that may either stand alone or may form part of

another structure. Description: May be considered as installations only the small towers that form part of a

building, especially if they are not attached to the ground. More significant and/or more independent towers shall be considered as Building or BuildingPart.

Value: windTurbine

Definition: A device that converts kinetic energy from the wind into mechanical energy. Description: Only the (generally small) wind turbines attached to or serving a building shall be

classified under installations. The self-standing and generally big wind-turbines shall be classified under Building.



5.5.2.3.7. MaterialOfFacadeValue

MaterialOfFacadeValue Name: Material Of Facade Definition: Code list for the possible values of MaterialOfFacade Status: Proposed Stereotypes: «codeList» Extensibility: any Identifier: null Value: asbestos

Definition: Façade constructed out of asbestos.

Value: ceramicTiles

Definition: Ceramic tiles of different colours and design are used for covering the façade of the building.

Description: EXAMPLES: ceramic tiles are commonly used in Portugal.

Value: composite

Definition: Composite material, such as plastics, PVC and fibreglass are used to cover the façade of the building.

Value: concrete

Definition: The surface of the façade is constructed out of (reinforced, with bars or fibres-other than asbestos) concrete.

Value: glass

Definition: Known as structural glass, is used for glazing the façade of buildings through the use of curtain wall systems, frameless glazing systems, polycarbonate sheeting or architectural flat glass.

Value: limestone

Definition: The façade of the building is composed of limestone, a sedimentary rock composed largely of calcite and/or aragonite.

Description: Limestone was commonly used for the construction of many medieval churches and castles in Europe, it was widely used in the 19th and early 20th centuries, and in countries like Malta, for a long time, the only building material available.

Value: masonry

Definition: The façade consists of individual units made of fired clay brick or concrete block laid in and bound together by mortar.

Value: metal

Definition: The surface of the building is covered with metal in the form of galvanized steel with paint, aluminium with paint, stainless steel, zinc, lead or copper.

Value: naturalStone

Definition: The façade is covered with natural stone, such as granite or marble, and may come in different colours and finishing.

Description: NOTE: If the façade is covered by limestone (that is also natural stone), the building should preferably be classified under “limestone” material of façade.

Value: vegetated

Definition: The façade is covered with vegetation and a growing medium, planted over a waterproofing membrane

Value: wood

Definition: The façade of the building is covered with wood, timber or lumber.



MaterialOfFacadeValue

Value: adobe

Definition: Use of a particular type of masonry for the façade, that involves the use of clay bricks (adobe) formed in moulds and (traditionally) dried in the sun.

5.5.2.3.8. MaterialOfRoofValue

MaterialOfRoofValue Name: Material Of Roof Definition: Code list for possible values of attribute MaterialOfRoof Status: Proposed Stereotypes: «codeList» Extensibility: any Identifier: http://inspire.ec.europa.eu/codeList/MaterialOfRoofValue Value: asbestos

Definition: Fibre reinforced concrete that includes asbestos fibres. Description: NOTE: It is commonly used for the agricultural sector, particularly in livestock

buildings.

Value: ceramicTile

Definition: Tiles made of ceramic material of different colours. They are traditionally of the barrel type, what is referred to today as cap and pan roof tiles.

Value: clayTile

Definition: Is a specific type of ceramic tile, made of fired terracotta. It is generally semi-cylindrical, made by forming clay around a curved surface and laid in alternating columns of convex and concave tiles.

Value: composition

Definition: Composition shingles are the most widely used roofing material. They are also called asphalt shingles that could either be organic fibre mat or fibreglass core. Both types are steeped in asphalt and then coated with mineral granules to add colour and texture. Most shingles have an adhesive back that when reinforced with tacks, staples or nails for attaching on roof frames would result in a tight fit.

Value: concreteTile

Definition: Roofing material consisting of shingles, simulated wood shakes, lighter-weight tiles and concrete panels manufactured from a variety of fibre-reinforced cement products.

Description: NOTE 1: Some are coated with plastics, enamels, or thin metals, and some contain recycled material. NOTE 2: Many concrete tiles mimic the appearance of wood shakes, while improving on the durability and fire protection that real wood affords. It can approximate the look of clay tile or slate while mitigating the structural problems caused by the weight of the real material.

Value: corrugatedSheet

Definition: Roofs of corrugated sheet may be of fibreglass, PVC or metal; less frequent is the use of galvanized iron sheet.

Value: glass

Definition: The surface of the roof is constructed out of glass, typically used in roofs covering internal atriums or in greenhouses.

Value: hotMoppedAsphalt



MaterialOfRoofValue Definition: Hot mopped asphalt roofing is usually applied to flat or semi-flat residential roofs

that have good access and proper drainage. Description: NOTE: In residential use it is often covered with a layer of decorative stone to

improve the appearance.

Value: metal

Definition: Metal roofing comes in the form of galvanized steel with paint, aluminium with paint, stainless steel, zinc, lead or copper. It is also manufactured in the form of imitation wood shingles.

Description: EXAMPLE : Standing-seam steel roofing is the most popular residential metal roofing today (the term standing-seam describes the upturned edge of one metal panel that connects it to adjacent sections, creating distinctive vertical lines and a trendy historical look). NOTE 1: Metal roofing is sturdy, lightweight, and non-combustible NOTE 2: Roofs in corrugated metal should preferably be classified under corrugatedSheet.

Value: reinforcedConcrete

Definition: Roofs constructed out of reinforced concrete, normally along flat or semi-flat surfaces used in terraces or inclined roofs.

Value: slate

Definition: Slate is a shingle-like sliver of rock or natural stone, offering a natural look laid out in a variety of patterns. It comes in different sizes and colours, although colours are limited to those found in nature.

Description: NOTE: Like tile, slate can be very heavy.

Value: thatch

Definition: Roofs are built by thatching, which is the craft of building a roof with dry vegetation such as straw, water reed, sedge, rushes and heather, layering the vegetation so as to shed water away from the inner roof.

Value: vegetatedGreenRoof

Definition: Also known as eco-roofs, a vegetated or green roof is a roof of a building that is partially or completely covered with vegetation and a growing medium, planted over a waterproofing membrane. It may also include additional layers such as a root barrier and drainage and irrigation systems.

Value: woodShinglesOrShakes

Definition: Wood shingles or shakes are differentiated by size and texture. Shingles are cut to a specific size and have smooth finish. Shakes are rough-textures and are irregular in shape.

5.5.2.3.9. MaterialOfStructureValue

MaterialOfStructureValue Name: Material Of Structure Definition: Code list for possible values of attribute MaterialOfStructure. Description: SOURCE: possible values adapted from the WHE Pager project Status: Proposed Stereotypes: «codeList» Extensibility: any Identifier: http://inspire.ec.europa.eu/codeList/MaterialOfStructureValue Value: mudWalls



MaterialOfStructureValue Definition: Mud walls may be made of stacked earth or poured earth. Stacked earth consists

in forming balls of plastic soil, which are freshly stacked on each other. Poured earth walls on the other hand are erected between formwork using a sandy material with coarse to fine granular particles. The ultimate finish can be natural - from the formwork- or sand blasted.

Description: NOTE 1: The contemporary name of stacked earth is cob ( a name derived from the British Isles). Cob does not use bricks, or blocks. Instead, wall surfaces can be sculpted into smooth, sinuous forms. A cob home may have sloping walls, arches and lots of wall niches. Modern cob construction may top the walls with a concrete bond beam, use a wooden bond beam, or a separate roof frame supported on a post and beam system.

Value: precastConcreteTilt-upWalls

Definition: Precast wall panel construction. Buildings of this type are low-rise structures with precast reinforced concrete wall panels that are often poured on the ground and tilted into place. Roofs are often composed of either plywood sheathing or metal decking, and glass curtain walls may exist at the building perimeter.

Value: reinforcedConcrete

Definition: The load resisting system is made of reinforced concrete, a combination of steel reinforcement bars embedded in concrete that act together in resisting forces. Reinforced concrete buildings may be constructed as moment resisting frames (beams and columns framing at nodes), or in combination with shear walls.

Value: reinforcedMasonry

Definition: Buildings of this type have exterior walls consisting of grouted (with concrete) masonry (clay brick or concrete block masonry) with internal reinforcing steel rods.

Description: Reinforced masonry buildings are relatively thick walled box-like structures and often have small windows and at least two mostly solid walls.

Value: rubleStoneMasonry

Definition: Ruble stone is field stone. Is a masonry technique that incorporates any material found or recovered, such as dressed blocks, broken fragments, brick or flint.

Description: NOTE 1: The success of rubble depends on the thickness of the wall and the strength of the binding mortar. If either is too thin, the structure will fail. As it is almost impossible to construct a thin rubble wall, owing to the irregularity of the material and the size of the gaps to be filled by the mortar, in areas or building traditions lacking dressed stone and ashlar technology, rubble walls are likely to be very thick.

Value: steel

Definition: The load resisting system of the building is made of structural steel, which may be made composite with reinforced concrete at floor slabs. Steel structures may be constructed as moments resisting frames, as concentrically or eccentrically braced frames, or as spatial trusses. The members of the structure may be bolted or welded.

Value: stoneMasonryBlock

Definition: Consist of masonry buildings constructed with stone blocks cut from igneous, metamorphic or sedimentary rocks. This type of buildings are generally unreinforced and may be joined with lime/cement mortar.

Value: wood

Definition: The load resisting system of the building is made of wood, timber or lumber.



MaterialOfStructureValue Description: Two systems of construction are possible, one based on a frame, the other on a

skeleton. Framing is a building technique based around structural members, usually called studs, which provide a stable frame to which interior and exterior wall coverings are attached. In skeleton houses the posts and the horizontal crossbars form a frame (whose strength is sometimes increased by the use of additional diagonal bracings or stiffeners) that is filled in with wood (post or frame and plank constructions) or other materials such as clay, stone, or brick.

Value: adobeBlockWalls

Definition: Also known as moulded earth, is a building technique that involves the use of clay bricks (adobe) formed in moulds and (traditionally) dried in the sun.

Description: NOTE: These unbaked bricks consist of sand, sometimes gravel, clay, water and often straw or grass mixed together by hand, formed in wooden moulds and dried by the sun. When machinery is not available, earth is manually tamped in the mould; else, mechanical compression is used (manual, or motorized presses), in order to accommodate large production outputs of compressed earth blocks.

Value: concreteBlockMasonry

Definition: Unreinforced concrete block masonry, with lime/cement mortar. Description: Buildings of this type have perimeter walls, and possibly some interior walls,

constructed of unreinforced concrete blocks joined with lime/cement mortar. These perimeter walls are sometimes used as load bearing walls and have no internal reinforcing steel rods. Anchor plates are sometimes used to tie the walls to the floors and roof and are conspicuous from the outside of the structure.

Value: earth

Definition: Rammed earth or pneumatically impacted stabilized earth. Rammed earth construction (also referred to as tapial in Spanish, or else, pisé de terre, in France) is conducted by erecting wooden or metal forms for the walls and filling them with a moist cement stabilized earth mix which is compacted by pounding with hand tools (with conical or flat heads) or with a mechanical compactor. Metal rebar is often added to further increase ductility.

Description: NOTE 1: Different kinds of earth or mineral compounds are sometimes added to each earth layer for the sake of decoration. The finished walls are massive and monolithic, offering high strength, high thermal mass and high insulation. NOTE 2: High load bearing strength allows for multi-storey structures, usually based on floor decks supported by massive wood beams. NOTE 3: No surface finishing is used except for aesthetic effect.

Value: firedBrickMasonry

Definition: Unreinforced fired brick masonry. Buildings of this type have perimeter walls, and possibly some interior walls, constructed of unreinforced fired brick blocks. These perimeter walls are sometimes used as load bearing walls and have no internal reinforcing steel rods. Anchor plates are sometimes used to tie the walls to the floors and roof and are conspicuous from the outside of the structure. Unusual brick patterns may also indicate unreinforced fired brick masonry.

Value: informalConstructions

Definition: Parts of slums/squatters. Informal constructions are non-engineered and are built by self-builders without any professional input (i.e. neither during the design phase, nor the construction one).

Description: NOTE 1: The whole endeavour is usually based on observation from other nearby building sites, or (in the best of cases) on labour experience gained by the owners during their occupation as construction builders. NOTE 2: This type of buildings are in general of low quality and have many deficiencies that make them very vulnerable to hazards.



MaterialOfStructureValue

Value: massiveStoneMasonry

Definition: Massive stone masonry with lime/cement mortar. Is constructed with a coursed double leaf masonry, with the outer layers of stonework levelled as the construction progresses and follows a well established masonry bond. The stone units are cut in regular dimensions. To improve the connection between cross walls better quality units are used for the bond in these areas.

Value: mobileHomes

Definition: A structure designed or adapted for human habitation which is capable of being moved from one place to another (whether by being towed, or by being transported on a motor vehicle or trailer) and any motor vehicle so designed or adapted.

Description: NOTE 1: Railway carriages and tents do not count as mobile homes. NOTE 2: Though mobile in nature, some mobile homes are in fact installed in perennial way and should be considered as under INSPIRE scope.

5.5.2.3.10. OfficialAreaReferenceValue

OfficialAreaReferenceValue Name: Official Area Reference 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).

Status: Proposed Stereotypes: «codeList» Extensibility: null Identifier:

5.5.2.3.11. OfficialValueReferenceValue

OfficialValueReferenceValue Name: Official Value Reference Definition: The list of possible values for referencing the official value of a building, building

part or building unit. Status: Proposed Stereotypes: «codeList» Extensibility: any Identifier: http://inspire.ec.europa.eu/codeList/OfficialValueReferenceValue Value: rentalIncome

Name: rental income Definition: The reference for official value is the rental income for the building or building

unit, according to market prices.

Value: transactionPriceSimple

Name: transaction price simple Definition: The reference for official value is the market price for transaction (selling,

inheritance, …) of the building or building unit alone.

Value: transactionPriceMedium

Name: transaction price medium



OfficialValueReferenceValue Definition: The reference for official value is the market price for transaction (selling,

inheritance, …) of the building and of the land on which the building is erected. In case of a building unit, the transaction price medium includes the building unit and the ratio of land associated to the building unit.

Value: transactionPriceFull

Name: transaction price full Definition: The reference for official value is the market price for transaction (selling,

inheritance, …) of the building and of the cadastral parcel on which the building is erected. In case of a building unit, the transaction price medium includes the building unit and the ratio of cadastral parcel associated to the building unit.

5.5.2.3.12. OtherConstructionNatureValue

OtherConstructionNatureValue Name: Other Construction Nature Definition: Code list for the attribute construction nature. Status: Proposed Stereotypes: «codeList» Extensibility: any Identifier: http://inspire.ec.europa.eu/codeList/OtherConstructionNatureValue Value: acousticFence

Definition: Environmental noise barrier system.

Value: antenna

Name: antenna Definition: A transducer designed to transmit or receive electromagnetic waves (includes

radio and tv masts, radar towers and satellite telecommunications). Description: Only self-standing antennas shall be considered as OtherConstruction. Antennas

attached to buildings shall be considered as Installation.

Value: bridge

Name: bridge Definition: A structure built to span a valley, road, body of water, or other physical obstacle,

for the purpose of providing passage over the obstacle.

Value: chimney

Name: chimney Definition: A vertical structure containing a passage or flue for discharging smoke and

gases of combustion. Description: Only self-standingchimneys shall be considered as OtherConstruction. Chimneys

attached to buildings shall be considered as Installation.

Value: cityWall

Name: cityWall Definition: A fortification (usually historic) used to defend a city or settlement or used to

enclose settlements.

Value: crane

Definition: A machine for lifting, shifting and lowering objects or material by means of a swinging boom or with the lifting apparatus supported on overhead track.

Description: Cranes that are permanently installed or used should be considered under scope of theme Buildings.

Value: monument



OtherConstructionNatureValue Definition: A structure erected to commemorate persons or events. Description: The monuments that are significant by their height (such as columns, obelisks),

by their size (such as monumental stairs, city gates) or by their fame are especially expected by INSPIRE.

Value: openAirPool

Name: openAirPool Definition: A swimming-pool that is not covered. Description: Open-air pools are of interest for fire risk.

Value: protectiveStructure

Definition: A construction providing protection against environmental hazrds, such as avalanches, mudslides, rock falls and landslides etc.

Value: pylon

Name: pylon Definition: Any elongated tall support structure used to support an overhead power line.

Value: retainingWall

Definition: A structure designed and constructed to resist the lateral pressure of soil when there is a desired change in ground elevation that exceeds the angle of repose of the soil.

Value: solarPanel

Definition: A solar panel is a packaged, connected assembly of solar cells, also known as photovoltaic cells. The solar panel can be used as a component of a larger photovoltaic system to generate and supply electricity in commercial and residential applications.

Description: May be considered as other construction, the self-standing solar panels, especially if they cover a significant area. The solar panels attached to a building should be classified as installation.

Value: substation

Name: substation Definition: Part of an electrical generation, transmission and distribution system where

voltage is transformed from high to low, or the reverse.

Value: tunnel

Name: tunnel Definition: An underground passage that is open at both ends and usually contains a land

transportation route (for example: a road and/or a railway).

5.5.2.3.13. OtherStandardOfficialAreaReferenceValue

OtherStandardOfficialAreaReferenceValue Name: Other Standard Official Area Reference Subtype of: OfficialAreaReferenceValue Definition: List of possible values for the official area reference, when provided using

another standard than the CLGE measurement code for the floor area of buildings. The other standard may be a national one or it may be the CEN standard (CEN pr 15221 Facility Management - Part 6: Area and Space Measurement) that is especially suitable for facilities.

Description: NOTE: The list of possible values is provided as an empty, extensible code list that has to be defined at Member State level.

Status: Proposed Stereotypes: «codeList»



OtherStandardOfficialAreaReferenceValue Extensibility: any Identifier:

5.5.2.3.14. RoofTypeValue

RoofTypeValue Name: Roof Type Definition: Code list for the possible values of attribute roofType. Status: Proposed Stereotypes: «codeList» Extensibility: any Identifier: http://inspire.ec.europa.eu/codeList/RoofTypeValue Value: archRoof

Definition: A roof taking the form of a semicircular span connected.

Value: conicalRoof

Definition: An inverted cone roof construction usually atop of a cylindrical tower.

Value: domedRoof

Definition: Roof formed of a thin curved structural slab. Description: NOTE: a slab is a thick, flat or shaped component usually larger than 300 mm

square, used to form a covering or projecting from a building.

Value: dualPentRoof

Definition: A roof that has two or more single plane roofs, usually separated or connected by vertical walls.

Value: flatRoof

Definition: Roof either horizontal or with a slope of 10° or less.

Value: gabledRoof

Definition: Pitched roof that terminates at one or both ends as a gable. Description: NOTE 1: a pitched roof is a roof whose slope is greater than 10° (approximately

15 %) NOTE 2: a gable is portion of a wall above the level of the eaves that encloses the end of the space under a pitched roof

Value: halfHippedRoof

Definition: A roof where all planes slope down to the supporting walls but with the upper point of the gable squared off.

Value: hippedRoof

Definition: Pitched roof with hip end or ends. Description: NOTE 1: a pitched roof is a roof whose slope is greater than 10° (approximately

15 %) NOTE 2: a hip is the inclined meeting line of two inclined planes in a pitched roof which forms a salient angle

Value: hyperbolicParabaloidalRoof

Definition: A roof constructed with two axes with one plane following a convex curve and another a concave curve.

Value: mansardRoof

Definition: Pitched roof with two inclined planes on each side of the ridge , the steeper of the two starting at the eaves



RoofTypeValue Description: NOTE 1: A ridge is the intersection at the top of two inclined planes in a pitched

roof which forms the apex of the roof. NOTE 2: Eave is lower edge of a pitched roof or edge of a flat roof.

Value: monopitchRoof

Definition: Pitched roof that has only a single plane. Description: NOTE: a pitched roof is a roof whose slope is greater than 10° (approximately 15

%).

Value: pavilionRoof

Definition: A roof construction with equal hips on all planes, usually taking the form of a pyramidal shape.

Value: pyramidalBroachRoof

Definition: A suspended roof construction with all four planes meeting at a central point.

Value: sawToothRoof

Definition: Series of pitched roofs , each with one inclined plane steeper than the other and fully or partially glazed


This section lists definitions for feature types, data types and enumerations 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.4.1. Address

Address Package: INSPIRE Consolidated UML Model::Themes::Annex I::Addresses::Addresses

[Include reference to the document that includes the package, e.g. INSPIRE data specification, ISO standard or the GCM]

Definition: An identification of the fixed location of property by means of a structured composition of geographic names and identifiers.



Address Description: NOTE 1 The spatial object, referenced by the address, is defined as the

"addressable object". The addressable object is not within the application schema, but it is possible to represent the address' reference to a cadastral parcel or a building through associations. It should, however, be noted that in different countries and regions, different traditions and/or regulations determine which object types should be regarded as addressable objects. NOTE 2 In most situations the addressable objects are current, real world objects. However, addresses may also reference objects which are planned, under construction or even historical. NOTE 3 Apart from the identification of the addressable objects (like e.g. buildings), addresses are very often used by a large number of other applications to identify object types e.g. statistics of the citizens living in the building, for taxation of the business entities that occupy the building, and the utility installations. NOTE 4 For different purposes, the identification of an address can be represented in different ways (see example 3). EXAMPLE 1 A property can e.g., be a plot of land, building, part of building, way of access or other construction, EXAMPLE 2 In the Netherlands the primary addressable objects are buildings and dwellings which may include parts of buildings, mooring places or places for the permanent placement of trailers (mobile homes), in the UK it is the lowest level of unit for the delivery of services, in the Czech Republic it is buildings and entrance doors. EXAMPLE 3 Addresses can be represented differently. In a human readable form an address in Spain and an address in Denmark could be represented like this: "Calle Mayor, 13, Cortijo del Marqués, 41037 Écija, Sevilla, España" or "Wildersgade 60A, st. th, 1408 Copenhagen K., Denmark".

5.5.2.4.2. AddressRepresentation

AddressRepresentation Package: INSPIRE Consolidated UML Model::Themes::Annex I::Addresses::Addresses


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.5.2.4.3. Area

Area Package: Model::ISO TC211::ISO 19103 Conceptual Schema Language::ISO 19103:2005

Schema Language::Basic Types::Derived::Units of Measure [Include reference to the document that includes the package, e.g. INSPIRE data specification, ISO standard or the GCM]





III::Buildings::BuildingCore2D [Include reference to the document that includes the package, e.g. INSPIRE data specification, ISO standard or the GCM]



BuildingNatureValue Package: INSPIRE Consolidated UML Model::Themes::Annex


Definition: List of possible values for the nature of a building. 5.5.2.4.6. CadastralParcel

CadastralParcel Package: INSPIRE Consolidated UML Model::Themes::Annex I::Cadastral

Parcels::CadastralParcels [Include reference to the document that includes the package, e.g. INSPIRE data specification, ISO standard or the GCM]

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.5.2.4.7. ConditionOfConstructionValue

ConditionOfConstructionValue Package: INSPIRE Consolidated UML Model::Themes::Annex


Definition: List of possible values for the condition of a construction of a real world object. 5.5.2.4.8. CurrentUse

CurrentUse Package: INSPIRE Consolidated UML Model::Themes::Annex


Definition: This data type enables to detail the current use(s) of the real world object. 5.5.2.4.9. CurrentUseValue

CurrentUseValue Package: INSPIRE Consolidated UML Model::Themes::Annex


Definition: List of possible values for the current use of the real world object. Description: SOURCE: This code list is partly based on and adapted from the Eurostat





DateOfEvent Package: INSPIRE Consolidated UML Model::Themes::Annex


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

5.5.2.4.11. DateTime

DateTime Package: Model::ISO TC211::ISO 19103 Conceptual Schema Language::ISO 19103:2005

Schema Language::Basic Types::Primitive::Date and Time [Include reference to the document that includes the package, e.g. INSPIRE data specification, ISO standard or the GCM]

5.5.2.4.12. DocumentReferenceWithStatus

DocumentReferenceWithStatus Package: INSPIRE Consolidated UML Model::Generic Conceptual Model::Base

Types::Base Types 2::Drafts - for x-TWG discussion::Document reference [Include reference to the document that includes the package, e.g. INSPIRE data specification, ISO standard or the GCM]

Definition: Unique identifier or citation to unambiguously reference a legal act or a specific part of a legal act.


Elevation Package: INSPIRE Consolidated UML Model::Themes::Annex


Definition: This data types includes the elevation of the real world object and information about how this elevation was measured.

5.5.2.4.14. ExternalReference

ExternalReference Package: INSPIRE Consolidated UML Model::Themes::Annex


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

5.5.2.4.15. GM_Primitive

GM_Primitive (abstract) Package: Model::ISO TC211::ISO 19107 Spatial Schema::ISO 19107:2003 Spatial

Schema:: Geometry::Geometric primitive [Include reference to the document that includes the package, e.g. INSPIRE data specification, ISO standard or the GCM]




Definition: Proper noun applied to a real world entity.


HeightAboveGround



HeightAboveGround Package: INSPIRE Consolidated UML Model::Themes::Annex


Definition: This data type includes the height above ground of the real world object and information about how this height was captured.

5.5.2.4.18. Integer

Integer Package: Model::ISO TC211::ISO 19103 Conceptual Schema Language::ISO 19103:2005

Schema Language::Basic Types::Primitive::Numerics [Include reference to the document that includes the package, e.g. INSPIRE data specification, ISO standard or the GCM]

5.5.2.4.19. Length

Length Package: Model::ISO TC211::ISO 19103 Conceptual Schema Language::ISO 19103:2005




5.6 Application schema <extended 3D >

5.6.1 Description

In the next version of data specification, a new way to present the model might be proposed in order to ensure that extended 3D profile is a formal extension of core 3D profile and/or to make model easier to understand. Content won’t change.

5.6.1.1. Narrative description Extended 3D profile is an illustrative profile for rich 3D building data. It is an ambitious profile, based on: - the semantics of extended 2D profile. - the same geometric representation of buildings as in core 3D, with all the LoDs (Levels of Detail) of City GML being allowed the 3D representation of all other instanciable feature types (building boundaries, installations, , building units, rooms, constructions) - a simplified profile of the Appearance model of CityGML.



5.6.1.1.1. Common semantics with extended2D profile

Figure n°58 : the feature types in white are carrying the semantics attributes they are the same as in

Extended2D profile, the feature types in blue are specific to extended 3d profile and are related to the geometric representation of buildings.

Figure n° 58 to be updated

5.6.1.1.2. The 3D building model As in core 2D, the building/building part 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.



Figure n°59: Modeling of LoD2 and LoD3

Figure n° 60 (source Karlsruhe Institute of Technology): 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; 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.

LoD3

LoD2



Figure n°61: the representation of building interior Figure n° 61 to be updated (BuildingUnit and Room represented just by GM_Solid)

5.6.1.1.3. Geometry of 3D feature types The geometry of 3D feature types has to be provided using one of these 4 types:

- BuildingGeometry3D: it is the data type defined in core 3D profile. It is used to represent the objects always having a volume, i.e. buildings, building parts

- GM_Solid : it is the simple geometry primitive to represent interior the 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

- 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)

- ConstructionGeometry3D: this data type 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:

o An antenna may be represented by a vertical line o Solar panel may be represented by a surface o Dormer may be represented by a volume / solid.

Geometry for construction to be clarified.



5.6.1.1.4. The appearance model

Figure n° 62: The appearance part (simplification of CityGML appearance model) More explanations about CityGML and INSPIRE 3D profiles may be found in annex C.



5.6.1.2. UML Overview class BuildingExtended3D

«featureType»BoundarySurface

«featureType»WallSurface

«voidable»+ materialOfWall: MaterialOfFacadeValue [0..1]

«featureType»RoofSurface

«voidable»+ materialOfRoof: MaterialOfRoofValue [0..*]

«featureType»GroundSurface

«featureType»OtherConstruction

+ constructionNature: OtherConstructionNatureValue


constraints

{GeometryWhenNoParts}


constraints

{MandatoryGeometry}

«featureType»Opening

«featureType»ClosureSurface

«featureType»Room

+ roomNature: RoomNatureValue [0..1]

AbstractBuildingWith3DGeometry



AbstractConstructionWith3DGeometry

+ geometry3D: ConstructionGeometry3D [0..*]


AbstractBuildingUnitWith3DGeometry

+ geometry3D: GM_Solid [1..*]

«featureType»InteriorInstallation

+ installationNature: InternalInstal lationNatureValue

«featureType»OuterCeilingSurface

«featureType»OuterFloorSurface

«featureType»AbstractBoundaryFeature

+ geometry3D: BoundaryGeometry3D

«featureType»Door

«featureType»Window

«featureType»BuildingExtended2D::

OtherConstructionNatureValue::

AbstractFeature


«voidable, l i feCycleInfo»+ beginLifespanVersion: DateTime+ endLifespanVersion: DateTime [0..1]


«voidable»+ bui ldingNature: Bui ldingNatureValue+ currentUse: CurrentUseValue+ numberOfBui ldingUnits: Integer [0..1]+ specificInterest: Bui ldingNatureValue+ numberOfDwell ings: Integer [0..1]+ numberOfFloorsAboveGround: Integer [0..1]+ address:: Address [0..*]

«featureType»Installation

+ installationNature: Instal lationNatureValue

Name: BuildingExtended3DAuthor: karjohVersion: 3.0Created: 2011-04-08 10:44:53Updated: 2012-04-26 15:54:30

«featureType»CadastralParcels::CadastralParcel

A

AbstractInteriorInstallationWith3DGeometry

+ geometry3D: ConstructionGeometry3D [1..*]

«featureType»AbstractBuildingExtended2D

«voidable»+ address: AddressRepresentation [0..*]+ connectionToElectrici ty: boolean [0..1]+ connectionToGas: boolean [0..1]+ connectionToSewage: boolean [0..1]+ connectionToWater: boolean [0..1]+ document: DocumentReferenceWithStatus [0..*]+ energyPerformance: EnergyPerformanceValue [0..1]+ floorDescription: FloorDescription [0..*]+ floorDistribution: FloorRange [1..*]+ heatingSource: HeatingSourceValue [0..*]+ heatingSystem: HeatingSystemValue [0..*]+ heightBelowGround: Length [0..1]+ materialOfFacade: MaterialOfFacadeValue [0..*]+ materialOfRoof: MaterialOfRoofValue [0..*]+ materialOfStructure: MaterialOfStructureValue [0..*]+ numberOfFloorsBelowGround: Integer [0..1]+ officialArea: OfficialArea [0..*]+ officialValue: OfficialValue [0..*]+ roofType: RoofTypeValue [0..*]


«voidable»+ conditionOfConstruction: ConditionOfConstructionValue+ dateOfConstruction: DateOfEvent [0..1]+ dateOfDemoli tion: DateOfEvent [0..1]+ dateOfRenovation: DateOfEvent [0..1]+ elevation: Elevation [0..*]+ externalReference: ExternalReference [0..*]+ heightAboveGround: HeightAboveGround [0..*]+ name: GeographicalName [0..*]

«featureType»BuildingUnit

+ externalReference: ExternalReference

«voidable»+ address: AddressRepresentation [0..*]+ connectionToElectrici ty: boolean [0..1]+ connectionToGas: boolean [0..1]+ connectionToSewage: boolean [0..1]+ connectionToWater: boolean [0..1]+ currentUse: CurrentUseValue [0..*]+ document: DocumentReferenceWithStatus [0..*]+ energyPerformance: EnergyPerformanceValue [0..*]+ heatingSource: HeatingSourceValue [0..*]+ heatingSystem: HeatingSystemValue [0..*]+ officialArea: OfficialArea [0..*]+ officialValue: OfficialValue [0..*]

+interiorInstal lation 0..*

+room

+cadastralParcel«voidable» 0..*

+cadastralParcel«voidable»

0..*

+room 0..*

+bui ldingUnit

0..*

+boundedBy 0..*

+parts 0,2...*

+opening 0..*

Figure n° 63 – UML class diagram: Overview of the BuildingExtended3D application schema



class BuildingExtended3DAppearance

«dataType»TextCoordGen

+ worldToTexture: TransformationMatrix3x4Type

«dataType»TextCoordList

+ ring: URI+ textureCoordinates: Number [0..*] {ordered}

«dataType»TextureParametrization

«featureType»ParameterizedTexture

+ imageURI: URI+ mimeType: MimeFileType+ textureType: TextureTypeType

«codeList»MimeFileType

+ image/gif+ image/jpeg+ image/png+ image/ti ff+ image/bmp

«dataType»TransformationMatrix3x4Type

+ elements: Number [0..*] {ordered}

«codeList»TextureTypeType

«voidable»+ specific+ typical

Name: BuildingExtended3DAppearanceAuthor: karjohVersion: 3.0Created: 2012-02-23 00:19:55Updated: 2012-04-19 09:53:46

+textureParams 1..*

uri:anyURI

+texture

Figure n° 64 – UML class diagram: Overview of the BuildingExtended3DAppearance application schema



class BuildingExtended3DCodeListsDataTypes

«dataType»BoundaryGeometry3D

+ LoD2MultiSurface: GM_MultiSurface [0..1]+ LoD3MultiSurface: GM_MultiSurface [0..1]+ LoD4MultiSurface: GM_MultiSurface [0..1]

«voidable»+ horizontalGeometryEstimatedAccuracyLoD2: Length [0..1]+ horizontalGeometryEstimatedAccuracyLoD3: Length [0..1]+ horizontalGeometryEstimatedAccuracyLoD4: Length [0..1]+ verticalGeometryEstimatedAccuracyLoD2: Length [0..1]+ verticalGeometryEstimatedAccuracyLoD3: Length [0..1]+ verticalGeometryEstimatedAccuracyLoD4: Length [0..1]

constraints

{atLeastOneMandatoryGeometry}

«codeList»InternalInstallationNatureValue

+ airConditioningUnit+ column+ elevator+ escalator+ fireside+ oven+ pipe+ radiator+ rafter+ rai l ing+ stairs+ ventilator

tags

extensibi li ty = anyvocabulary = http://inspire.ec.europa.eu/codeList/InternalInstal lationNatureValue

«codeList»RoomNatureValue

+ accomodationWaste+ administration+ agricultureForestry+ businessTrade+ catering+ churchInstitution+ communicating+ habitation+ healthCare+ industry+ management+ recreation+ security+ schoolEducationResearch+ store+ traffic

tags

extensibl il ty = anyvocabulary = http://inspire.ec.europa.eu/codeList/RoomNatureValue

Name: BuildingExtended3DCodeListsDataTypesAuthor: karjohVersion: 3,0Created: 2012-02-07 00:21:49Updated: 2012-04-26 11:51:33

«dataType»ConstructionGeometry3D

+ horizontalGeometryReferenceLoD1: HorizontalGeometryReferenceValue [0..1]+ horizontalGeometryReferenceLoD2: HorizontalGeometryReferenceValue [0..1]+ LoD1Geometry: GM_Object [0..1]+ LoD1TerrainIntersection: GM_MultiCurve [0..1]+ LoD2Geometry: GM_Object [0..1]+ LoD2TerrainIntersection: GM_MultiCurve [0..1]+ LoD3Geometry: GM_Object [0..1]+ LoD3TerrainIntersection: GM_MultiCurve [0..1]+ LoD4Geometry: GM_Object [0..1]+ LoD4TerrainIntersection: GM_MultiCurve [0..1]+ verticalGeometryReference3DLoD1Bottom: ElevationReferenceValue [0..1]+ verticalGeometryReference3DLoD1Top: ElevationReferenceValue [0..1]+ verticalGeometryReference3DLoD2Bottom: ElevationReferenceValue [0..1]+ verticalGeometryReference3DLoD3Bottom: ElevationReferenceValue [0..1]+ verticalGeometryReference3DLoD4Bottom: ElevationReferenceValue [0..1]

«voidable»+ horizontalGeometryEstimatedAccuracyLoD1: Length [0..1]+ horizontalGeometryEstimatedAccuracyLoD2: Length [0..1]+ horizontalGeometryEstimatedAccuracyLoD3: Length [0..1]+ horizontalGeometryEstimatedAccuracyLoD4: Length [0..1]+ verticalGeometryEstimatedAccuracyLoD1: Length [0..1]+ verticalGeometryEstimatedAccuracyLoD2: Length [0..1]+ verticalGeometryEstimatedAccuracyLoD3: Length [0..1]+ verticalGeometryEstimatedAccuracyLoD4: Length [0..1]

Figure n° 65 – UML class diagram: Overview of the BuildingExtended3DCodeListsDataTypes application schema

5.6.1.3. Consistency between spatial data sets Idem core 3D.


5.6.1.5. Modelling of object references Idem core 3D.

5.6.1.6. Geometry representation Idem core 3D.

5.6.1.7. Temporality representation Idem core 3D.




Table 3 - Feature catalogue metadata

Feature catalogue name INSPIRE feature catalogue BuildingExtended3D Scope BuildingExtended3D Version number 2.9 Version date 2012-04-20 Definition source INSPIRE data specification BuildingExtended3D

Table 4 - Types defined in the feature catalogue

Type Package Stereotypes Section AbstractBoundaryFeature BuildingExtended3D «featureType» 5.2.2.1.1 AbstractBuilding BuildingExtended3D «featureType» 5.2.2.1.2 AbstractBuildingExtended2D BuildingExtended3D «featureType» 5.2.2.1.3 AbstractConstruction BuildingExtended3D «featureType» 5.2.2.1.4 BoundaryGeometry3D BuildingExtended3D «dataType» 5.2.2.2.1 BoundarySurface BuildingExtended3D «featureType» 5.2.2.1.5 Building BuildingExtended3D «featureType» 5.2.2.1.6 BuildingPart BuildingExtended3D «featureType» 5.2.2.1.7 BuildingUnit BuildingExtended3D «featureType» 5.2.2.1.8 ClosureSurface BuildingExtended3D «featureType» 5.2.2.1.9 ConstructionGeometry3D BuildingExtended3D «dataType» 5.2.2.2.2 Door BuildingExtended3D «featureType» 5.2.2.1.10 GroundSurface BuildingExtended3D «featureType» 5.2.2.1.11 Installation BuildingExtended3D «featureType» 5.2.2.1.12 InteriorInstallation BuildingExtended3D «featureType» 5.2.2.1.13 InternalInstallationNatureValue BuildingExtended3D «codeList» 5.2.2.3.1 MimeFileType BuildingExtended3D «codeList» 5.2.2.3.2 Opening BuildingExtended3D «featureType» 5.2.2.1.14 OtherConstruction BuildingExtended3D «featureType» 5.2.2.1.15 OuterCeilingSurface BuildingExtended3D «featureType» 5.2.2.1.16 OuterFloorSurface BuildingExtended3D «featureType» 5.2.2.1.17 ParameterizedTexture BuildingExtended3D «featureType» 5.2.2.1.18 RoofSurface BuildingExtended3D «featureType» 5.2.2.1.19 Room BuildingExtended3D «featureType» 5.2.2.1.20 RoomNatureValue BuildingExtended3D «codeList» 5.2.2.3.3 TextCoordGen BuildingExtended3D «dataType» 5.2.2.2.3 TextCoordList BuildingExtended3D «dataType» 5.2.2.2.4 TextureParametrization BuildingExtended3D «dataType» 5.2.2.2.5 TextureTypeType BuildingExtended3D «codeList» 5.2.2.3.4 TransformationMatrix3x4Type BuildingExtended3D «dataType» 5.2.2.2.6 WallSurface BuildingExtended3D «featureType» 5.2.2.1.21 Window BuildingExtended3D «featureType» 5.2.2.1.22


5.6.2.1.1. AbstractBoundaryFeature

AbstractBoundaryFeature (abstract) Name: Abstract Boundary Feature Subtype of: AbstractFeature



AbstractBoundaryFeature (abstract) Status: Proposed Stereotypes: «featureType» Identifier: null Attribute: geometry3D

Value type: BoundaryGeometry3D Multiplicity: 1


AbstractBuilding (abstract) Name: Abstract Building Subtype of: AbstractBuildingWith3DGeometry Definition: Abstract feature type grouping the semantic common properties of instanciable

feature types Building and BuildingPart. Status: Proposed Stereotypes: «featureType» Identifier: null Attribute: buildingNature

Value type: BuildingNatureValue Definition: Characteristics of the building that makes it generally of interest for mapping

purposes. Description: NOTE 1: The characteristic may be related to the physical aspect and/or to the

function of the building. Multiplicity: 1 Stereotypes: «voidable» Obligation: Technical Guidance (recommendation)


Value type: CurrentUseValue Definition: Activity hosted by the real world object. Description: NOTE: This attribute addresses mainly the buildings hosting human activities. Multiplicity: 1 Stereotypes: «voidable» Obligation: Technical Guidance (recommendation)

Attribute: numberOfBuildingUnits



Description: Building Unit is a feature type aimed at subdividing a whole building or a building part into smaller parts that are treated as separate entities in daily life.A BuildingUnit is homogeneous, regarding management aspects. EXAMPLES: It may be e.g. an apartment in a multi-owner building, a terraced house, or a shop inside a shopping arcade. NOTE: 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.


Attribute: specificInterest

Value type: BuildingNatureValue



AbstractBuilding (abstract) Multiplicity: 1 Stereotypes: «voidable» Obligation: Technical Guidance (recommendation)


Value type: Integer Multiplicity: 0..1 Stereotypes: «voidable»

Attribute: numberOfFloorsAboveGround


Attribute: address:

Value type: Address Multiplicity: 0..* Stereotypes: «voidable»


Value type: CadastralParcel Multiplicity: 0..* Stereotypes: «voidable»

5.6.2.1.3. AbstractBuildingExtended2D

AbstractBuildingExtended2D (abstract) Name: Abstract Building Extended2D Subtype of: AbstractBuilding Definition: Abstract feature type grouping the additional properties of Building and Building

Part. Description: The additonal properties are those that are not already included in the core2D

profile. Status: Proposed Stereotypes: «featureType» Identifier: null Attribute: connectionToElectricity


electricity network. Multiplicity: 0..1 Stereotypes: «voidable» Obligation: null


Value type: boolean Definition: An indication if the building or building part is connected or not to the public gas





AbstractBuildingExtended2D (abstract) Value type: boolean Definition: An indication if the building or building part is connected or not to the public

sewage network. Multiplicity: 0..1 Stereotypes: «voidable» Obligation: null


Value type: boolean Definition: An indication if the building or building part connected or not to the public water


Attribute: document

Value type: DocumentReferenceWithStatus Definition: Any document providing information about the building or building part. 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



Value type: EnergyPerformanceValue Definition: The energy performance of the building or building part. Description: 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» Obligation: Technical Guidance (recommendation)

Attribute: floorDescription

Value type: FloorDescription Definition: The description of a given range of building floors. Multiplicity: 0..* Stereotypes: «voidable»

Attribute: floorDistribution

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»


Value type: HeatingSourceValue Definition: The source of energy used for the heating Description: EXAMPLES: electricity, natural gas Multiplicity: 0..* Stereotypes: «voidable» Obligation: Technical Guidance (recommendation)



AbstractBuildingExtended2D (abstract)



Attribute: heightBelowGround

Value type: Length Definition: Height below ground of the building or building part. Multiplicity: 0..1 Stereotypes: «voidable»

Attribute: materialOfFacade

Value type: MaterialOfFacadeValue Definition: Material(s) of the building or building part facade. Multiplicity: 0..* Stereotypes: «voidable» Obligation: Technical Guidance (recommendation)

Attribute: materialOfRoof

Value type: MaterialOfRoofValue Definition: Material(s) of the building or building part roof. Multiplicity: 0..* Stereotypes: «voidable» Obligation: Technical Guidance (recommendation)

Attribute: materialOfStructure

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» Obligation: Technical Guidance (recommendation)

Attribute: numberOfFloorsBelowGround

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»


Value type: OfficialArea Definition: The area of the building or building part as registered in an official information



Value type: OfficialValue



AbstractBuildingExtended2D (abstract) Definition: The value of the buildingor building part as registered in official information


Attribute: roofType

Value type: RoofTypeValue Definition: The shape of the roof. Multiplicity: 0..* Stereotypes: «voidable» Obligation: Technical Guidance (recommendation)

Attribute: address

Value type: AddressRepresentation Definition: The address(es) of the building or building part. Description: This attribute provides the current address(es) of the building in the structured

data type defined in theme Address. Multiplicity: 0..* Stereotypes: «voidable»

Association role: buildingUnit

Value type: BuildingUnit Multiplicity: 0..*


AbstractConstruction (abstract) Name: Abstract Construction Subtype of: AbstractFeature Definition: Abstract feature type grouping common properties of instanciable feature types

Building, BuildingPart and OtherConstruction. Status: Proposed Stereotypes: «featureType» Identifier: null Attribute: conditionOfConstruction

Value type: ConditionOfConstructionValue Definition: Status of the construction related to its real world life-cycle. Multiplicity: 1 Stereotypes: «voidable» Obligation: Technical Guidance (recommendation)

Attribute: dateOfConstruction

Value type: DateOfEvent Definition: NOTE: this attribute has multiplicity 0..1 because =in case the construction is

only under project, the date of construction may not exist yet. Multiplicity: 0..1 Stereotypes: «voidable»

Attribute: dateOfDemolition

Value type: DateOfEvent Definition: Date of demolition of the construction,if any. -- Note -- It is not mandatory to give

neither the time nor the day or the month. Multiplicity: 0..1



AbstractConstruction (abstract) Stereotypes: «voidable»

Attribute: dateOfRenovation

Value type: DateOfEvent Definition: Date of last major renovation of the construction, if any. Multiplicity: 0..1 Stereotypes: «voidable»

Attribute: elevation

Value type: Elevation Definition: Vertical-constrained dimensional property of the construction consisting of an

absolute measure referenced to a well-defined surface which is commonly taken as origin (geoid, water level, etc.)

Description: Source: adapted from definition given by TWG EL Multiplicity: 0..* Stereotypes: «voidable»



related to the construction. Description: EXAMPLE 1: reference to another spatial data set containing another view on

constructions; the externalReference may be used for instance to ensure consistency between 2D and 3D representations of the same constructions EXAMPLE 2: reference to cadastral or dwelling register. The reference to this register may enable to find legal information related to the construction, 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 construction physical and temporal aspects.


Attribute: heightAboveGround

Value type: HeightAboveGround Definition: Height above ground of the construction Description: NOTE: height above ground may be defined as the difference between elevation



Attribute: name

Value type: GeographicalName Definition: Name of the construction. Description: Examples: Big Ben, Eiffel Tower Multiplicity: 0..* Stereotypes: «voidable»

Association role: boundedBy

Value type: BoundarySurface Definition: The boundary surface being part of the exterior shell of the construction. Multiplicity: 0..*



5.6.2.1.5. BoundarySurface

BoundarySurface Name: Boundary Surface Subtype of: AbstractBoundaryFeature Definition: Features being part of the building?s exterior shell with a special function. Description: EXAMPLES: wall (WallSurface), roof (RoofSurface), ground plate

(GroundSurface) or ClosureSurface. Status: Proposed Stereotypes: «featureType» Identifier: null Association role: opening

Value type: Opening Definition: The opening(s) being part of the boundary surface. Multiplicity: 0..*

5.6.2.1.6. Building

Building Name: Building Subtype of: AbstractBuildingExtended2D Definition: A Building is an enclosed construction above and/or underground, used or



Value type: BuildingPart Definition: The building part(s) composint the building. Multiplicity: 0,2...*

Constraint: GeometryWhenNoParts

Natural language:

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


BuildingPart Name: Building Part Subtype of: AbstractBuildingExtended2D Definition: A BuildingPart is a sub-division of a Building that might be considered itself as a


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

Status: Proposed Stereotypes: «featureType» Identifier: null Constraint: MandatoryGeometry



BuildingPart Natural

language: A BuildingPart must provide at least one geometry3D.

5.6.2.1.8. BuildingUnit

BuildingUnit Name: Building Unit Subtype of: AbstractBuildingUnitWith3DGeometry 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: BuildingUnit is a feature type aimed at subdividing a whole building or a building part into smaller parts that are treated as seperate entities in daily life. A BuildingUnit is homogeneous, regarding management aspects. EXAMPLE: It may be e.g. an apartment in a condominium, a terraced house, or a shop inside a shopping arcade. NOTE: 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.

Status: Proposed Stereotypes: «featureType» Identifier: null Attribute: address

Value type: AddressRepresentation Definition: The address(es) of the building unit. Description: This attribute provides the current address(es) of the building unit in the

structured data type defined in themeAddress. Multiplicity: 0..* Stereotypes: «voidable»

Attribute: connectionToElectricity

Value type: boolean Definition: An indication if the building unit is connected or not to the public electricity



Value type: boolean Definition: An indication if the building unit is connected or not to the public gas network. Multiplicity: 0..1 Stereotypes: «voidable» Obligation: null


Value type: boolean Definition: An indication if the building unit is connected or not to the public sewage





BuildingUnit Value type: boolean Definition: An indication if the building unit is connected or not to the public water network. Multiplicity: 0..1 Stereotypes: «voidable» Obligation: null


Value type: CurrentUseValue Definition: Activity hosted by the building unit. Multiplicity: 0..* Stereotypes: «voidable» Obligation: Technical Guidance (recommendation)

Attribute: document

Value type: DocumentReferenceWithStatus Definition: Any document providing information about the building unit. Description: EXAMPLES:A photo or a sketch of interior, the energy performance assessment. Multiplicity: 0..* Stereotypes: «voidable»


Value type: EnergyPerformanceValue Definition: The energy performance of the building unit. Description: The energy performance is required by the Energy Performance of Building

Directive for the new buildings being rent or sold. Multiplicity: 0..* Stereotypes: «voidable» Obligation: Technical Guidance (recommendation)



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


Value type: HeatingSourceValue Definition: The source of energy used for the heating. Description: EXAMPLES: electricity, natural gas Multiplicity: 0..* Stereotypes: «voidable» Obligation: Technical Guidance (recommendation)


Value type: HeatingSystemValue Definition: The system of heating Description: EXAMPLES : stove, central heting, heat pump Multiplicity: 0..*



BuildingUnit Stereotypes: «voidable» Obligation: Technical Guidance (recommendation)


Value type: OfficialArea Definition: The area of the building unit as registered in an official information system. Multiplicity: 0..* Stereotypes: «voidable»


Value type: OfficialValue Definition: The value of the building as registered in official information system. Multiplicity: 0..* Stereotypes: «voidable»

Association role: room

Value type: Room Multiplicity: 0..*


Value type: CadastralParcel Definition: The room(s) composing the building unit. Multiplicity: 0..* Stereotypes: «voidable»

5.6.2.1.9. ClosureSurface

ClosureSurface Name: Closure Surface 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.


5.6.2.1.10. 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 Lo2 or Lo3 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.




5.6.2.1.11. GroundSurface

GroundSurface Name: Ground Surface Subtype of: BoundarySurface Definition: A feature 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 Status: Proposed Stereotypes: «featureType» Identifier: null 5.6.2.1.12. Installation

Installation Name: Installation Subtype of: AbstractConstructionWith3DGeometry Definition: An external construction (of small size) or an external device serving the building

or building part. Description: EXAMPLES: stairway, solar panel, external lift Status: Proposed Stereotypes: «featureType» Identifier: null Attribute: installationNature

Value type: InstallationNatureValue Definition: A description of the real world object that represents its intended nature or

current function. Multiplicity: 1 Obligation: Technical Guidance (recommendation)

5.6.2.1.13. InteriorInstallation

InteriorInstallation Name: Interior Installation Subtype of: AbstractInteriorInstallationWith3DGeometry Definition: An internal construction (generally of small size) or an internal device. Description: Serving the building or BuildingPart

EXAMPLE: stairs, lift Status: Proposed Stereotypes: «featureType» Identifier: null Attribute: installationNature

Value type: InternalInstallationNatureValue Definition: The nature of the internal installation. Multiplicity: 1 Obligation: Technical Guidance (recommendation)

5.6.2.1.14. Opening

Opening Name: Opening Subtype of: AbstractBoundaryFeature 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.



Opening Description: NOTE: when using LoD2 or Lod3 of CityGML (as indicated in this INSPIRE

Extended3D profile), the feature type Opening is limited to the openings in the outer walls of the building Source : adapted from CityGML


5.6.2.1.15. OtherConstruction

OtherConstruction Name: Other Construction Subtype of: AbstractConstructionWith3DGeometry 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.

Status: Proposed Stereotypes: «featureType» Identifier: null Attribute: constructionNature

Value type: OtherConstructionNatureValue Definition: A description of the feature that represents its intended nature or current function

and which differentiates it from that of a Building. Multiplicity: 1 Obligation: Technical Guidance (recommendation)

5.6.2.1.16. OuterCeilingSurface

OuterCeilingSurface Name: Outer Ceiling Surface 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. Status: Proposed Stereotypes: «featureType» Identifier: null 5.6.2.1.17. OuterFloorSurface

OuterFloorSurface Name: Outer Floor Surface Subtype of: BoundarySurface Definition: A surface (feature) belonging to the outer building shell and with the orientation

pointing upwards. Description: EXAMPLES: The floor of a loggia. Status: Proposed Stereotypes: «featureType» Identifier: null



5.6.2.1.18. ParameterizedTexture

ParameterizedTexture Name: Parameterized Texture Definition: Texture representing the appearance aspect of a surface in the exterior shell of

the building. The feature type ParameterizedTexture describes a texture that is mapped to a surface (target).

Description: SOURCE: adapted from CityGML. Status: Proposed Stereotypes: «featureType» Identifier: null Attribute: imageURI

Value type: URI Definition: Uniform Resource Identifier; gives indication where the image used for the

texture may be found. Multiplicity: 1

Attribute: mimeType

Value type: MimeFileType Definition: Format of the image used for texture. Multiplicity: 1 Obligation: Technical Guidance (recommendation)

Attribute: textureType

Value type: TextureTypeType Definition: Type of the texture; gives indication if the texture comes from real-world images

or from standards images in libraries. Multiplicity: 1 Obligation: Technical Guidance (recommendation)

5.6.2.1.19. RoofSurface

RoofSurface Name: Roof Surface 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 Status: Proposed Stereotypes: «featureType» Identifier: null Attribute: materialOfRoof

Value type: MaterialOfRoofValue Definition: Material(s) of the building roof. Multiplicity: 0..* Stereotypes: «voidable» Obligation: Technical Guidance (recommendation)

5.6.2.1.20. Room

Room Name: Room Subtype of: AbstractBuildingUnitWith3DGeometry Definition: A room is any distinguishable space within a structure. Usually, a room is

separated from other spaces or passageways by interior walls; moreover, it is separated from outdoor areas by an exterior wall, sometimes with a door.



Room Status: Proposed Stereotypes: «featureType» Identifier: null Attribute: roomNature

Value type: RoomNatureValue Definition: The nature (intended use or function) of the room. Multiplicity: 0..1 Obligation: Technical Guidance (recommendation)

5.6.2.1.21. WallSurface

WallSurface Name: Wall Surface Subtype of: BoundarySurface Definition: The surfaces that are part of the building facade visible from the outside. Description: Source: adapted from CityGML. Status: Proposed Stereotypes: «featureType» Identifier: null Attribute: materialOfWall

Value type: MaterialOfFacadeValue Definition: Material(s) of the building exterior walls. Multiplicity: 0..1 Stereotypes: «voidable» Obligation: Technical Guidance (recommendation)

5.6.2.1.22. 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 LoD2 or LoD3 of CityGML (as indicated in INSPIRE Extended3D profile), the feature type Window is limited to the windows in the exterior shell of the building. Source : adapted from CityGML.

Status: Proposed Stereotypes: «featureType» Identifier: null 5.6.2.2. Data types

5.6.2.2.1. BoundaryGeometry3D

BoundaryGeometry3D Name: Boundary Geometry3D Definition: The information related to the boundary geometry as 3D data. Status: Proposed Stereotypes: «dataType» Identifier: null Attribute: horizontalGeometryEstimatedAccuracyLoD2



BoundaryGeometry3D 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.



Attribute: horizontalGeometryEstimatedAccuracyLoD3

Value type: Length Definition: The estimated absolute positional accuracy of the (X,Y) coordinates of the LoD3





Value type: Length Definition: The estimated absolute positional accuracy of the (X,Y) coordinates of the LoD3




Attribute: 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


Value type: GM_MultiSurface Definition: The geometry of the boundary, corresponding to the LoD3 of CityGML. --

Definition -- LoD3 of City GML represents the exact geometry of the building, approximating its true shape.

Multiplicity: 0..1




BoundaryGeometry3D Value type: GM_MultiSurface Definition: The geometry of the boundary, corresponding to the LoD4 of CityGML. --

Definition -- LoD3 of City GML represents the accurate geometry of the building, approximating its true shape.

Multiplicity: 0..1

Attribute: 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. -- Definition -- 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.





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.





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.


Constraint: atLeastOneMandatoryGeometry

Natural language:

At least one of the mandatory geometries must be provided:

5.6.2.2.2. ConstructionGeometry3D

ConstructionGeometry3D Name: Construction Geometry3D



ConstructionGeometry3D Status: Proposed Stereotypes: «dataType» Identifier: null Attribute: horizontalGeometryEstimatedAccuracyLoD1

Value type: Length Definition: The estimated absolute planimetric accuracy of the Lod1 building

representation, in the INSPIRE official Coordinate Reference System. Absolute planimetric 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.




Value type: Length Definition: The estimated absolute planimetric accuracy of the LoD2 building

representation, in the INSPIRE official Coordinate Reference System. Absolute planimetric 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.




Value type: Length Multiplicity: 0..1 Stereotypes: «voidable»



Attribute: horizontalGeometryReferenceLoD1

Value type: HorizontalGeometryReferenceValue Multiplicity: 0..1 Obligation: Technical Guidance (recommendation)

Attribute: horizontalGeometryReferenceLoD2

Value type: HorizontalGeometryReferenceValue Multiplicity: 0..1 Obligation: Technical Guidance (recommendation)

Attribute: LoD1Geometry

Value type: GM_Object Multiplicity: 0..1



ConstructionGeometry3D

Attribute: LoD1TerrainIntersection

Value type: GM_MultiCurve Definition: (Multi)Line where the feature (Building, BuildingPart, ...) touches the terrain

representation in LoD1. Description: In case of a simple building feature, the TerrainIntersectionCurve is a simple line

string surrounding the feature. In case of more complex features (building with an atrium, building on columns, for example), the TerrainIntersectionCurve consists of multiple disconnected parts.

Multiplicity: 0..1







Multiplicity: 0..1







Multiplicity: 0..1







Multiplicity: 0..1


Value type: Length



ConstructionGeometry3D Definition: The estimated absolute height accuracy of the LoD1 building representation, in

the INSPIRE official Coordinate Reference System. Absolute height 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.




Value type: Length Definition: The estimated absolute height accuracy of the LoD2 building representation, in

the INSPIRE official Coordinate Reference System. Absolute height 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.




Value type: Length Definition: The estimated absolute height accuracy of the LoD3 building representation in

LoD3, in the INSPIRE official Coordinate Reference System. Absolute height 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. -- Definition -- 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.




Attribute: verticalGeometryReference3DLoD1Bottom

Value type: ElevationReferenceValue Multiplicity: 0..1 Obligation: Technical Guidance (recommendation)

Attribute: verticalGeometryReference3DLoD1Top



Value type: ElevationReferenceValue Multiplicity: 0..1



ConstructionGeometry3D Obligation: Technical Guidance (recommendation)





5.6.2.2.3. TextCoordGen

TextCoordGen Name: Text Coord Gen 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.

Status: Proposed Stereotypes: «dataType» Identifier: null Attribute: worldToTexture

Value type: TransformationMatrix3x4Type Definition: Matrix of the transformation between the file coordinates in an image to the real-

world coordinates of the building Multiplicity: 1

5.6.2.2.4. TextCoordList

TextCoordList Name: Text Coord List 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.

Status: Proposed Stereotypes: «dataType» Identifier: null Attribute: ring

Value type: URI Definition: Uniform Resource Identifier; gives indication where the ring (limit of image) may

be found. Multiplicity: 1

Attribute: textureCoordinates

Value type: Number Definition: List of coordinates in the texture file. Multiplicity: 0..* Collection

Constraints: ordered



5.6.2.2.5. TextureParametrization

TextureParametrization (abstract) Name: Texture Parametrization Definition: TextureParametrization is the abstract supertype of TextCoordGen and

TextCoordList. Is is used to relate both to a ParametrizedTexture. Status: Proposed Stereotypes: «dataType» Identifier: null Association role: texture

Value type: ParameterizedTexture Definition: The texture. Multiplicity:

5.6.2.2.6. TransformationMatrix3x4Type

TransformationMatrix3x4Type Name: Transformation Matrix3x4 Type Definition: A matrixproviding the transformation function between coordinates of the texture

and coordinates of real-world object. Status: Proposed Stereotypes: «dataType» Identifier: null Attribute: elements

Value type: Number Definition: The matrix elements. Multiplicity: 0..* Collection

Constraints: ordered

5.6.2.3. Code lists

5.6.2.3.1. InternalInstallationNatureValue

InternalInstallationNatureValue Name: Internal Installation Nature Status: Proposed Stereotypes: «codeList» Extensibility: any Identifier: http://inspire.ec.europa.eu/codeList/InternalInstallationNatureValue Value: airConditioningUnit

Name: air conditioning unit Definition: An air conditioning unit or air conditioner is a home appliance, system, or

mechanism designed to dehumidify and extract heat from an area. Description: Only the internal air conditioning units located inside the building shall be

considered as InternalBuildingInstallation.

Value: column

Name: column Definition: A column or pillar in architecture is a vertical structural element that transmits,

through compression, the weight of the structure above to other structural elements below.

Value: elevator

Name: elevator



InternalInstallationNatureValue Definition: An elevator is a type of vertical transport equipment that efficiently moves people

or goods between floors of a building.

Value: escalator

Name: escalator Definition: Any elongated tall support structure used to support an overhead power line.

Value: fireside

Name: fireside Definition: A fireside or fireplace is an architectural structure designed to contain a fire for

heating, as well as for cooking.

Value: oven

Name: oven Definition: An oven is a thermally insulated chamber used for the heating, baking or drying

of a substance.

Value: pipe

Name: pipe Definition: A pipe is a tubular section or hollow cylinder, usually but not necessarily of

circular cross-section, used mainly to convey substances which can flow — liquids and gases (fluids), slurries, powders, masses of small solids.

Value: radiator

Name: radiator Definition: Radiators and convectors are heat exchangers designed to transfer thermal

energy from one medium to another for the purpose of space heating.

Value: rafter

Name: rafter Definition: A rafter is one of a series of sloped structural members (beams), that extend

from the ridge or hip to the downslope perimeter or eave, designed to support the roof deck and its associated loads.

Value: railing

Name: railing Definition: A railing or handrail is a rail that is designed to be grasped by the hand so as to

provide stability or support. Handrails are commonly used while ascending or descending stairways and escalators in order to prevent injurious falls.

Value: stairs

Name: stairs Definition: Stairs are r a construction designed to bridge a large vertical distance by dividing

it into smaller vertical distances, called steps. Stairways may be straight, round, or may consist of two or more straight pieces connected at angles.

Value: ventilator

Name: ventilator Definition: A ventilator is a device use for ventilating. Ventilating is the process of

"changing" or replacing air in any space to provide high indoor air quality. Description: Ventilation is used to remove unpleasant smells and excessive moisture,

introduce outside air, to keep interior building air circulating, to control air temperature and to prevent stagnation of the interior air.

5.6.2.3.2. MimeFileType

MimeFileType



MimeFileType Name: Mime File Type Definition: Mime file types code list. Status: Proposed Stereotypes: «codeList» Extensibility: any Identifier: null Value: image/gif

Definition: *.gif images

Value: image/jpeg

Definition: *.jpeg, *.jpg images

Value: image/png

Definition: *.png images

Value: image/tiff

Definition: *.tiff, *.tif images

Value: image/bmp

Definition: *.bmp images

5.6.2.3.3. RoomNatureValue

RoomNatureValue Name: Room Nature Status: Proposed Stereotypes: «codeList» Extensibility: any Identifier: http://inspire.ec.europa.eu/codeList/RoomNatureValue Value: accomodationWaste

Value: administration

Value: agricultureForestry

Value: businessTrade

Value: catering

Value: churchInstitution

Value: communicating

Value: habitation



RoomNatureValue

Value: healthCare

Value: industry

Value: management

Value: recreation

Value: security

Value: schoolEducationResearch

Value: store

Value: traffic

5.6.2.3.4. TextureTypeType

TextureTypeType Name: Texture Type Type Definition: The texture type type. Status: Proposed Stereotypes: «codeList» Extensibility: any Identifier: null Value: specific

Definition: Specific means that the texture has been captured individually for that particular building.

Value: typical

Definition: Typical means that the texture is prototypic and typical for that type of building (e.g. a typical texture for a two storey residential home build in the 1950s.

5.6.2.4.





5.6.2.5.1. AbstractFeature

AbstractFeature (abstract) Package: INSPIRE Consolidated UML Model::Themes::Annex

III::Buildings::BuildingExtended2D [Include reference to the document that includes the package, e.g. INSPIRE data specification, ISO standard or the GCM]

Definition: Abstract feature type grouping common properties of all the instanciable feature types of this profile.

5.6.2.5.2. Address

Address Package: Model::ISO TC211::ISO 19133 Tracking and Navigation::Address Model [Include

reference to the document that includes the package, e.g. INSPIRE data specification, ISO standard or the GCM]

5.6.2.5.3. AddressRepresentation

AddressRepresentation Package: INSPIRE Consolidated UML Model::Themes::Annex I::Addresses::Addresses


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.








Definition: Data type grouping the different ways to provide the 3D geometry of a building or building part.


BuildingNatureValue



BuildingNatureValue Package: INSPIRE Consolidated UML Model::Themes::Annex


Definition: List of possible values for the nature of a building.

5.6.2.5.7. CadastralParcel

CadastralParcel Package: INSPIRE Consolidated UML Model::Themes::Annex I::Cadastral

Parcels::CadastralParcels [Include reference to the document that includes the package, e.g. INSPIRE data specification, ISO standard or the GCM]

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.5.8. ConditionOfConstructionValue

ConditionOfConstructionValue Package: INSPIRE Consolidated UML Model::Themes::Annex


Definition: List of possible values for the condition of a construction of a real world object.

5.6.2.5.9. CurrentUseValue

CurrentUseValue Package: INSPIRE Consolidated UML Model::Themes::Annex


Definition: List of possible values for the current use of the real world object. Description: SOURCE: This code list is partly based on and adapted from the Eurostat



DateOfEvent Package: INSPIRE Consolidated UML Model::Themes::Annex


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

5.6.2.5.11. DocumentReferenceWithStatus

DocumentReferenceWithStatus Package: INSPIRE Consolidated UML Model::Generic Conceptual Model::Base

Types::Base Types 2::Drafts - for x-TWG discussion::Document reference [Include reference to the document that includes the package, e.g. INSPIRE data specification, ISO standard or the GCM]

Definition: Unique identifier or citation to unambiguously reference a legal act or a specific part of a legal act.




Elevation Package: INSPIRE Consolidated UML Model::Themes::Annex


Definition: This data types includes the elevation of the real world object and information about how this elevation was measured.


ElevationReferenceValue Package: INSPIRE Consolidated UML Model::Themes::Annex


Definition: List of possible values for the element of the real world object that has been considered to capture its 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.6.2.5.14. EnergyPerformanceValue

EnergyPerformanceValue Package: INSPIRE Consolidated UML Model::Themes::Annex


Definition: Code list for possible values of energy performance of a building. 5.6.2.5.15. ExternalReference

ExternalReference Package: INSPIRE Consolidated UML Model::Themes::Annex


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

5.6.2.5.16. FloorDescription

FloorDescription Package: INSPIRE Consolidated UML Model::Themes::Annex


Definition: This data type gathers the main characteristics of the floor of a building. Description: The common characteristics are the ones coming from the use cases considered

by this data specification.

5.6.2.5.17. FloorRange

FloorRange Package: INSPIRE Consolidated UML Model::Themes::Annex


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



FloorRange 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.

5.6.2.5.18. GM_MultiCurve

GM_MultiCurve Package: Model::ISO TC211::ISO 19107 Spatial Schema::ISO 19107:2003 Spatial

Schema:: Geometry::Geometric aggregates [Include reference to the document that includes the package, e.g. INSPIRE data specification, ISO standard or the GCM]

5.6.2.5.19. GM_MultiSurface

GM_MultiSurface Package: Model::ISO TC211::ISO 19107 Spatial Schema::ISO 19107:2003 Spatial

Schema:: Geometry::Geometric aggregates [Include reference to the document that includes the package, e.g. INSPIRE data specification, ISO standard or the GCM]

5.6.2.5.20. GM_Object

GM_Object (abstract) Package: Model::ISO TC211::ISO 19107 Spatial Schema::ISO 19107:2003 Spatial

Schema:: Geometry::Geometry root [Include reference to the document that includes the package, e.g. INSPIRE data specification, ISO standard or the GCM]

5.6.2.5.21. GM_Solid

GM_Solid Package: Model::ISO TC211::ISO 19107 Spatial Schema::ISO 19107:2003 Spatial

Schema:: Geometry::Geometric primitive [Include reference to the document that includes the package, e.g. INSPIRE data specification, ISO standard or the GCM]




Definition: Proper noun applied to a real world entity.

5.6.2.5.23. HeatingSourceValue

HeatingSourceValue Package: INSPIRE Consolidated UML Model::Themes::Annex


5.6.2.5.24. HeatingSystemValue

HeatingSystemValue Package: INSPIRE Consolidated UML Model::Themes::Annex





HeightAboveGround Package: INSPIRE Consolidated UML Model::Themes::Annex


Definition: This data type includes the height above ground of the real world object and information about how this height was captured.


HorizontalGeometryReferenceValue Package: INSPIRE Consolidated UML Model::Themes::Annex


Definition: List of possible values for the element of the real world object that has been considered to capture its horizontal geometry.

Description: NOTE: The building component may be a BuildingPart or a BuildingUnit or a Room.

5.6.2.5.27. InstallationNatureValue

InstallationNatureValue Package: INSPIRE Consolidated UML Model::Themes::Annex


5.6.2.5.28. Integer

Integer Package: Model::ISO TC211::ISO 19103 Conceptual Schema Language::ISO 19103:2005


5.6.2.5.29. Length

Length Package: Model::ISO TC211::ISO 19103 Conceptual Schema Language::ISO 19103:2005


5.6.2.5.30. MaterialOfFacadeValue

MaterialOfFacadeValue Package: INSPIRE Consolidated UML Model::Themes::Annex


Definition: Code list for the possible values of MaterialOfFacade

5.6.2.5.31. MaterialOfRoofValue

MaterialOfRoofValue Package: INSPIRE Consolidated UML Model::Themes::Annex


Definition: Code list for possible values of attribute MaterialOfRoof



5.6.2.5.32. MaterialOfStructureValue

MaterialOfStructureValue Package: INSPIRE Consolidated UML Model::Themes::Annex


Definition: Code list for possible values of attribute MaterialOfStructure. Description: SOURCE: possible values adapted from the WHE Pager project

5.6.2.5.33. Number

Number (abstract) Package: Model::ISO TC211::ISO 19103 Conceptual Schema Language::ISO 19103:2005


5.6.2.5.34. OfficialArea

OfficialArea Package: INSPIRE Consolidated UML Model::Themes::Annex


Definition: This data types includes the official area of the building and information about the exact meaning of this area.

5.6.2.5.35. OfficialValue

OfficialValue Package: INSPIRE Consolidated UML Model::Themes::Annex


Definition: The official value is provided by a value and its currency. 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.

5.6.2.5.36. OtherConstructionNatureValue

OtherConstructionNatureValue Package: INSPIRE Consolidated UML Model::Themes::Annex


Definition: Code list for the attribute construction nature.

5.6.2.5.37. RoofTypeValue

RoofTypeValue Package: INSPIRE Consolidated UML Model::Themes::Annex


Definition: Code list for the possible values of attribute roofType.

5.6.2.5.38. URI

URI



URI Package: Model::ISO TC211::Drafts::ISO 19115-1 Metadata - Fundamentals::ISO 19115-1

Metadata - Fundamentals::Citation and responsible party information [Include reference to the document that includes the package, e.g. INSPIRE data specification, ISO standard or the GCM]



6 Reference systems

6.1 Coordinate reference systems

6.1.1 Datum

IR Requirement 5 For the coordinate reference systems used for making available the INSPIRE spatial data sets, the datum shall be the datum of the European Terrestrial Reference System 1989 (ETRS89) in areas within its geographical scope, and 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-established and described relationship between both systems, according to EN ISO 19111.

6.1.2 Coordinate reference systems

IR Requirement 6 INSPIRE spatial data sets shall be made available using one of the three-dimensional, two-dimensional or compound coordinate reference systems specified in the list below.

Other coordinate reference systems than those listed below may only be used

for regions outside of continental Europe. The geodetic codes and parameters for these coordinate reference systems shall be documented, and an identifier shall be created, according to EN ISO 19111 and ISO 19127.

1. Three-dimensional Coordinate Reference Systems

– Three-dimensional Cartesian coordinates – Three-dimensional geodetic coordinates (latitude, longitude and ellipsoidal height), using the

parameters of the GRS80 ellipsoid

2. Two-dimensional Coordinate Reference Systems – Two-dimensional geodetic coordinates, using the parameters of the GRS80 ellipsoid – Plane coordinates using the Lambert Azimuthal Equal Area projection and the parameters of

the GRS80 ellipsoid – Plane coordinates using the Lambert Conformal Conic projection and the parameters of the

GRS80 ellipsoid – Plane coordinates using the Transverse Mercator projection and the parameters of the GRS80

ellipsoid



3. Compound Coordinate Reference Systems – For the horizontal component of the compound coordinate reference system, one of the two-

dimensional coordinate reference systems specified above 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. The geodetic codes and parameters for these vertical reference systems shall be documented and an identifier shall be created, according to EN ISO 19111 and ISO 19127.

– For the vertical component in the free atmosphere, barometric pressure, converted to height using ISO 2533:1975 International Standard Atmosphere shall be used.

6.1.3 Display

IR Requirement 7 For the display of the INSPIRE spatial data sets with the View Service specified in D003152/02 Draft Commission Regulation implementing Directive 2007/2/EC of the European Parliament and of the Council as regards Network Services, at least the two dimensional geodetic coordinate system shall be made available.

6.1.4 Identifiers for coordinate reference systems

IR Requirement 8 For referring to the non-compound coordinate reference systems listed in this Section, the identifiers listed below shall be used.

For referring to a compound coordinate reference system, an identifier

composed of the identifier of the horizontal component, followed by a slash (/), followed by the identifier of the vertical component, shall be used.

- ETRS89-XYZ for Cartesian coordinates in ETRS89 - ETRS89-GRS80h for three-dimensional geodetic coordinates in ETRS89 on the GRS80 ellipsoid - ETRS89-GRS80 for two-dimensional geodetic coordinates in ETRS89 on the GRS80 - EVRS for height in EVRS - 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 - ETRS89-LAEA for ETRS89 coordinates projected into plane coordinates by the Lambert Azimuthal

Equal Area projection - ETRS89-LCC for ETRS89 coordinates projected into plane coordinates by the Lambert Conformal

Conic projection - ETRS89-TMzn for ETRS89 coordinates projected into plane coordinates by the Transverse

Mercator projection

6.2 Temporal reference system

IR Requirement 9 The Gregorian calendar shall be used for as a reference system for date values, and the Universal Time Coordinated (UTC) or the local time including the time zone as an offset from UTC shall be used as a reference system for time values.



6.3 Theme-specific requirements and recommendations on reference systems

Error! Not a valid filename.



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 7.2 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 7.2 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 2 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 2 – 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

7.1.1 Completeness – Commission

Recommendation 4 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 5 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 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 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 6 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

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)

Recommendation 7 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:

yields to the linear root mean square error RMSE = σz. Evaluation 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 8 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


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


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 …).



Figure n° 1: 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 gives the recommended minimum scale and accuracy for the various possible levels of detail of building data.

LoD 2 LoD 0 (2D) LoD1 (3D)

LoD 0 (2D) LoD1 (3D) LoD2 (2D) LoD2 (3D)

Feature types

Building Building BuildingPart

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


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

Table 2: Recommended minimum scale and accuracy for building data sets.



Recommendation 8 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. When using ISO 19115/19157/19139 to encode the metadata, the following rules should be followed:

• The scope element (of type DQ_Scope) of the DQ_DataQuality subtype should be used to encode the reporting scope. NOTE The reporting scope can be different from the evaluation scope (see section 7).

• Only the following values should be used for the level element of DQ_Scope: Series, Dataset, featureType. NOTE The value featureType is used to denote spatial object type.

• If the level is featureType the levelDescription/MDScopeDescription/features element (of type Set< GF_FeatureType>) shall be used to list the feature type names.

Mandatory or conditional metadata elements are specified in Section 8.1. Optional metadata elements are specified in Section 8. The tables describing the metadata elements contain 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. • The fourth column specifies the condition, under which the given element becomes

mandatory (only for Table 3 and Table 4).

8.1 Common metadata elements

IR Requirement 10 The metadata describing a spatial data set or a spatial data set series related to the theme Buildings shall comprise the metadata elements required by



Regulation 1205/2008/EC (implementing Directive 2007/2/EC of the European Parliament and of the Council as regards metadata) for spatial datasets and spatial dataset series (Table 3) as well as the metadata elements specified in Table 4.

Table 3 – Metadata for spatial datasets and spatial dataset series specified in Regulation 1205/2008/EC (implementing Directive 2007/2/EC of the European Parliament and of the Council as regards metadata)

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

Table 4 – Mandatory and conditional common metadata elements



INSPIRE Data Specification Buildings Section

Metadata element Multiplicity Condition

8.1.1 Coordinate Reference System

1

8.1.2 Temporal Reference System

0..* 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.

8.1.3 Encoding 1..*

8.1.4 Character Encoding 0..* Mandatory, if an encoding is used that is not based on UTF-8.

8.1.5

Data Quality – Logical Consistency – Topological Consistency

0..* Mandatory, if the data set includes types from the Generic Network Model and does not assure centreline topology (connectivity of centrelines) for the network.

8.1.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.1.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.


Example referenceSystemIdentifier: code: GregorianCalendar codeSpace: INSPIRE RS registry




<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.1.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 9 shall be used to document the default and alternative encodings.


Example

name: Buildings GML application schema version: version 3.0RC2, GML, version 3.2.1 specification: D2.8.III.2 Data Specification on Buildings – Draft Guidelines


<gmd:MD_Format> <gmd:name> <gco:CharacterString> Buildings GML application schema </gco:CharacterString> </gmd:name> <gmd:version> <gco:CharacterString>3.0RC2, GML, version 3.2.1</gco:CharacterString> </gmd:version> <gmd:specification> <gco:CharacterString>D2.8.III.2 Data Specification on Buildings – Draft Guidelines</gco:CharacterString> </gmd:specification> </gmd:MD_Format>

Comments



8.1.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 -


<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.1.5 Data Quality – Logical Consistency – Topological Consistency

Metadata element name Data Quality – Logical Consistency – Topological Consistency

Definition Correctness of the explicitly encoded topological characteristics of the dataset as described by the scope

INSPIRE obligation / condition Mandatory, if the data set includes types from the Generic Network Model and does not assure centreline topology (connectivity of centrelines) for the network.

INSPIRE multiplicity 0..*

Comments

See clauses on topological consistency in section 7 for detailed information. This metadata element is mandatory if connectivity is not assured for network centrelines in the dataset. In this case the Connectivity tolerance parameter – as described in section 7 – must be provided in order to ensure automatic and unambiguous creation of centreline topology in post-process.

NOTE See section 8.2 for further instructions on how to implement metadata elements for reporting data quality.

8.2 Metadata elements for reporting data quality

Recommendation 9 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.

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.



Recommendation 10 The metadata elements specified in the following tables 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 table applies to reporting quantitative results (using the element DQ_QuantitativeResult), while the second table applies to reporting non-quantitative results (using the element DQ_DescriptiveResult). NOTE These tables may need to be updated once the XML schemas for ISO 19157 have been finalised. 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 7. DQ_MeasureReference (C.2.1.3) 8. DQ_EvaluationMethod (C.2.1.4.) 9. DQ_Result (C2.1.5.)


39. nameOfMeasure NOTE This should be the name as defined in Chapter 7. 42. evaluationMethodType 43. 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. 46. dateTime NOTE This should be data or range of dates on which the data quality measure was applied. 63. 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 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 9. DQ_Result (C2.1.5.)


67. 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)


Open issue 4: For reporting compliance with minimum data quality requirements and recommendations specified in section 7, the INSPIRE conformity metadata element should be used. However, since this issue is part of the larger discussion on the Abstract Test Suite and the definition of conformance classes for the data specification, detailed instructions on how to provide metadata on compliance with minimum data quality requirements and recommendations will only be provided for v3.0.

8.3 Theme-specific metadata elements No mandatory theme-specific metadata elements are defined for this theme.

Recommendation 11 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 5.

Table 5 – Optional theme-specific metadata elements for the theme Buildings

Section Metadata element Multiplicity

8.3.1 Maintenance Information 0..1

8.3.2 ContentInformation <0..1 >

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 <ContentInformation > Metadata element name <MD_ContentInformation > Definition description of the content of a dataset ISO 19115 number and name MD_ContentInformation

ISO/TS 19139 path

<XPath to the element in ISO 19139> The schemas available at http://schemas.opengis.net/iso/19139/20060504/gmd/gmd.xsd shall be used.

INSPIRE obligation / condition optional INSPIRE multiplicity 0..1 Data type (and ISO 19115 no.)

MD_FeatureCatalogue Description

Domain MD_FeatureCatalogue


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 D 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.3 Template for additional information



8.4 Guidelines on using metadata elements defined in Regulation 1205/2008/EC

8.4.1 Conformity

The Conformity metadata element defined in Regulation 1205/2008/EC allows to report the conformance with the Implementing Rule for interoperability of spatial data sets and services or another specification. The degree of conformity of the dataset 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).

Recommendation 12 The Conformity metadata element should be used to report conceptual consistency with this INSPIRE data specification. The value of Conformant should be used for the Degree element only if the dataset passes all the requirements described in the abstract test suite presented in Annex A. The Specification element should be given as follows:

- title: “INSPIRE Data Specification on <Theme Name> – Draft Guidelines” - date: - dateType: publication - date: 2012-07-09

Open issue 5: Conformance testing is still an open issue under discussion. Instructions on conformance testing and a common abstract test suite (including detailed instructions on how to test specific requirements) will be added at a later stage. This may also lead to an update of the recommendations on how to fill the conformity metadata element.

8.4.2 Lineage

Recommendation 13 Following the ISO 19113 Quality principles, if a data provider has a procedure for quality validation of their spatial data sets then the data quality elements listed in the Chapters 7 and 8 should be used. 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 specify that the statement sub-element of LI_Lineage (EN ISO 19115) should be used to implement the lineage metadata element.

Recommendation 14 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 This recommendation is based on the conclusions of the INSPIRE Data Quality Working Group to avoid overloading of the overall lineage statement element with information on the transformation steps and related source data. NOTE 2 In order to improve the interoperability, domain templates and instructions for filling these free text elements (descriptions) may be specified in an Annex of this data specification.

Open issue 6: The suggested use of the LI_Lineage sub-elements needs to be discussed as part of the maintenance of the INSPIRE metadata Technical Guidelines.

8.4.3 Temporal reference

According to Regulation 1205/2008/EC, at least one of the following temporal reference metadata elements shall be provided: temporal extent, date of publication, date of last revision, date of creation. If feasible, the date of the last revision of a spatial data set should be reported using the Date of last revision metadata element.

8.4.4 <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.

Figure n° 67

Recommendation 9 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.4.4.1. Source

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


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.

2. 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 dayly updated by field work on these basis. building.



8.4.4.2. ProcessStep

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


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

2. the coordinate transformation to make initial source compliant with INSPIRE

3. 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

2. 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)

3. 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.

9 Delivery

9.1 Delivery medium

TG Requirement 2 Data conformant to this INSPIRE data specification shall be made available through an INSPIRE network service.

TG Requirement 3 All information that is required by a calling application to be able to retrieve the data through the used network service shall be made available in accordance with the requirements defined in the Implementing Rules on Network Services.

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 proviced 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.2 Encodings

9.2.1 Default Encoding(s)

TG Requirement 4 Data conformant to the application schema core 2D defined in section 5.2 shall be encoded using the encoding(s) specified in this section.

TG Requirement 5 Data conformant to the application schema core 3D defined in section 5.3 shall be encoded using the encoding(s) specified in this section.

9.2.1.1. Default encodings for application schema <core 2D > Name: <core 2D > GML Application Schema or <extended 2D > GML Application Schema Version: version <version of the GML Application Schema>, GML, version 3.2.1 Specification: D2.8.III.2 Data Specification on Buildings – Draft Guidelines Character set: UTF-8 The GML Application Schemas are distributed in a zip-file separately from the data specification document.

9.2.1.2. Default encodings for application schema <core 3D > Name: <core 3D > GML Application Schema or <extended 3D > GML Application Schema Version: version <version of the GML Application Schema>, GML, version 3.2.1 Specification: D2.8.III.2 Data Specification on Buildings – Draft Guidelines Character set: UTF-8 The GML Application Schemas are distributed in a zip-file separately from the data specification document.



9.2.1.2.1. Implementation UML model used for generating the GML application schema The GML application schema was not derived directly from the conceptual model described in section 5, but from an implementation model (for a schematic illustration of this process, see Figure ).

Figure n° 68 – Process of creating the GML application schema (from [DS-D2.7])

9.3 Error! Not a valid filename.Scope of theme Buildings

9.3.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.



Figure n°69 : the modular approach for scope of theme Buildings

9.3.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 INSPIRE, 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 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 10 OtherConstructions should be made available for INSPIRE, as much as possible.

9.3.3 Definition of theme buildings Are considered under theme Buildings the are enclosed 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 11 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 there is a strong need to have a “construction view” about them, i.e. except if attributes such as height or date of construction are required by use cases.

9.4 Use of Building and BuildingPart

9.4.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). EXAMPLE 1

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 n°70 : split into building parts (example 1)

A

B



EXAMPLE 2

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)


generalised Building (e.g. with number of floors above ground

= 20) Figure n°71 : split into building parts (example 2)

EXAMPLE 3:

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 n°72 : split into building parts (example 3)

EXAMPLE 4:

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)


generalised Building with date of construction = 1920 (and date of renovation = 1950 if

enlargement is considered as renovation)

Figure n°73 : split into building parts (example 4)

B A C

A B

A

B



9.4.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.

Figure n° 74: example from Germany

In figure 6, 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:



Figure n° 75: example from Spain

In figure x+1, 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

This building has been split into 3 building parts This building has been split into 4 building parts Figure n°76 : 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]

A

B1

C A

B C B2



9.4.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: o number of dwelling on Building = sum of number of dwellings of the BuildingParts

composing the Building o similar rule with numberOfBuildingUnit

- Among the other attributes: o The specific attributes shall and can be filled only on Building Parts o The common attributes should be filled only on Buildings.

9.5 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 D) Example 1: from Dutch Dwelling Register to INSPIRE Residential Lodging Industrial Office Retail Education Meeting Prison Healthcare Sports Other

Figure n° 77 : matching example from national classification to INSPIRE classification of current use

Example 2 : from Eurostat classification to INSPIRE



Eurostat classification INSPIRE classification Residential buildings

One-dwelling buildings Two- and more dwelling

buildings - two dwellings - more than two

dwellings Residences for

communities Non-residential buildings

Industrial buildings and warehouses

Office buildings Hotels and similar

buildings Wholesale and retail

trade buildings Traffic and

communication buildings Public entertainment,

education, hospital or institutional care buildings

Other non-residential buildings - religious buildings - historic monuments - farm buildings - other

Figure n° 78: matching example from EUROSTAT classification to INSPIRE classification of current use

NOTE 1: some data producers have already implemented the Eurostat classification.

9.6 Temporal aspects

Figure n° 79: 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).

9.6.1 Data type DateOfEvent

Figure n° 80: 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 o beginning: void o end: void o anyPoint: 1978

- producer knows that construction took place before 1950 o beginning: void o end: 1950 o anyPoint: void

- producer knows that construction took place between 1800 and 1900 o beginning: 1800 o end: 1900 o anyPoint: void

- producer knows that construction took place between 12/04/2008 and 25/12/2010 o beginning: 12/04/2008 o end :25/12/2010 o anyPoint: void

9.6.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)

o its attribute endLifespanVersion gets value “15/05/2010” o its attribute dateOfDemolition gets value “20/03/2010” o 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 : o the attribute endLifespanVersion of the old version of the building will get value

“15/05/2010” o the attribute dateOfDemolition of the old version remains empty

o the other attributes stay as they are, describing the building as it was just before being demolished (e.g. its attribute conditionOfConstruction remains “functional”)

o the attribute beginLifespanVersion of the new version of the building will get value “15/05/2010”

o the attribute endLifespanVersion of the new version of the building remains empty

o the attribute conditionOfConstruction of the new version will get value “demolished” o 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..

9.7 Use of ElevationCRSReference Open issue 7: If JRC decides to accept the MS comment that requests to replace attributes value

and elevationReferenceSystem by an attribute value defined as DirectPosition, this paragraph will have to be updated.

Attribute elevation is defined as shown below.



Figure n°81 : the elevation data type

The data type VerticalCRSIdentifier is an imported type from theme Elevation; for simplicity reasons, this data type is a profile (subset) of the data type RS_Identifier defined in ISO 19115. This data type is composed of 3 attributes:

- code: identifier of the Elevation Reference System in the registry or namespace - codeSpace: identification of the namespace or registry - version: version of the registry/namespace

The concept of ElevationCRSReference allows the possibility to reference the Elevation

Reference System in any registry. It may be a national registry or the future INSPIRE registry

of Coordinate Reference Systems.

However, by the time being, the registry used more often is the EPSG (European Petroleum

Survey Group) registry.

This registry may be accessed on www.epsg-registry.org

EXAMPLE

A data producer provides a measure of elevation in EVRF 2007 (that is a realisation of EVRS,

the Vertical Reference System recommended by INSPIRE) and indicates the Elevation

Reference system used by a Reference in the EPSG registry

Extract from EPSG register

Data type VerticalCRSIdentifier will be filled as follow:

- verticalCRSId

o code: EPSG::5621

o nameSpace: EPSG



o version: 7.9.5

9.8 Extension of code lists The code lists regarding classification of Building (currentUseValue and BuildingNature) are extensible by Member States.

9.8.1 Hierarchical code list (CurentUseValue) Code list currentUse has a hierarchical structure and may be extended only by giving more detailed level; this is expressed in Feature Catalogue by extensibility being “narrower”. EXAMPLE: The hierarchic code list currentUse might be extended, giving for instance more details under value agriculture.

• residential − Individual − Collective

- twoDwellings - moreThanTwoDwellings

• agriculture − culture − breeding − storage

• industry • commercesAndServices

− office − retail − publicService

• ancillary In this case, a mechanism should be set up to ensure that a user requiring buildings whose currentUse is “agriculture” would also receive buildings whose currentUse is “culture”, “breeding” and “storage”.

9.8.2 Other code lists The other INSPIRE code lists that are not hierarchical and that are extensible may be extended both by giving more details under a current value or by giving other values independent from the ones that are in the INSPIRE code list. In case of giving more details, a mechanism to retrieve child values from parent ones must be implemented. EXAMPLE: the attribute buildingNature might be extended as follow

• ….. • storageTank • synagogue • temple • tower

• controlTower

• lookoutTower

• clockTower • coolingTower

• communicationTower

• windmill • windTurbine



• windmill • kiosk

• phoneBooth

• busShelter

9.9 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.



10 Portrayal This clause defines the rules for layers and styles to be used for portrayal of the spatial object types defined for this theme. In section 10.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 on a specific topic. Section 10.2 specifies the styles that shall be supported by INSPIRE view services for each of these layer types. In section Error! Reference source not found., 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. Where XML fragments are used in these 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) If an INSPIRE view service supports the portrayal of data related to the theme Buildings, it shall provide layers of the types specified in this section. If an INSPIRE view network service supports the portrayal of spatial data sets corresponding to the spatial data theme Buildings, it shall support the styles specified in section 10.2. If no user-defined style is specified in a portrayal request for a specific layer to an INSPIRE view service, the default style specified in section 10.2 for that layer shall be used. In addition to the styles defined in section 10.2, it is recommended that, where applicable, INSPIRE view services also support the styles defined in section Error! Reference source not found..

10.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.

10.1.1 Layers organisation None.

10.2 Styles to be supported by INSPIRE view services



10.2.1 Styles for the layer <Building >

Layer Name Building

Style Name BU.Building.Default

Style Title <Building Default Style>

Style Abstract The building reference geometry is represented by following styles:

- Style for surface geometries: grey with black outline o Fill colour: SOLID GREY RGB 128,128,128 o Outline colour: SOLID BLACK o Outline width: 0,4pt

- Style for point geometries: dark grey circle o Style: CIRCLE o Fill colour: SOLID DARK GREY (RGB 82,82,82) o 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/BuildingsCore2D/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>



Scale 1/1000 Scale 1/ 10 000 Point representation

Figure n°82 : 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.

Layer Name BuildingPart

Style Name <BU.BuildingPart.default>

Style Title <BuildingPart default StyleStyle>

Style Abstract

The building reference geometry is represented by following styles: - Style for surface geometries: hollow with black outline

o Fill colour: TRANSPARENT o Outline colour: SOLID BLACK o Outline width: 0,2pt

- Style for point geometries: grey circles o Style: CIRCLE o Fill colour: SOLID GREY (RGB 128,128,128) o 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/BuildingsCore2D/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> </sld:UserStyle> </sld:NamedLayer>

Minimum & maximum scales

<1/50> - <1/10 000>

Scale 1/500 Scale 1/500 ; BuildingPart combined with Building Building must be bottom layer BuildingPart must be top layer

Figure n° 83: examples of BuildingPart portrayal NOTE 2: the legend proposed by INSPIRE aims to represent Building and BuildingPart as reference data, with neutral colours. This legend is especially suitable when buildings are represented together with other more coloured layers, such as Land Use, Land Cover, Natural Risk Zones …. More attractive legends to represent theme Buildings alone may/should be proposed by the data providers and are up to them.



Bibliography CLASSIFICATION OF TYPES OF CONSTRUCTIONS -Eurostat- 15/10/1997

Creating a global building inventory for earthquake loss assessment and risk management, Open-file Report 2008-1160", US Department if the Interior and US Geological survey, USA.- Jaiswal K., Wals D. (2008)

Measurement code for the floor area of buildings – CLGE

DEVELOPING A PRAGMATIC APPROACH TO ASSESS URBAN METABOLISM IN EUROPE]- A Report to the European Environment Agency - Stockholm Environment Institute & Technische Universität Berlin- 2010 Regulation (EC) No 763/2008 of the European Parliament and of the Council on population and housing censuses as regards the technical specifications of the topics and of their breakdowns DIRECTIVE 2002/49/EC OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 25 June 2002 relating to the assessment and management of environmental noise - Official Journal of the European Communities DIRECTIVE 2002/91/EC OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 16 December 2002 on the energy performance of buildings - Official Journal of the European Communities DIRECTIVE 2008/50/EC OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 21 May 2008 on ambient air quality and cleaner air for Europe - Official Journal of the European Communities OpenGIS® City Geography Markup Language (CityGML) Encoding Standard – v1.1 [DS-D2.3] INSPIRE DS-D2.3, Definition of Annex Themes and Scope, v3.0,

http://inspire.jrc.ec.europa.eu/reports/ImplementingRules/DataSpecifications/D2.3_Definition_of_Annex_Themes_and_scope_v3.0.pdf

[DS-D2.5] INSPIRE DS-D2.5, Generic Conceptual Model, v3.3,

http://inspire.jrc.ec.europa.eu/documents/Data_Specifications/D2.5_v3_3.pdf [DS-D2.6] INSPIRE DS-D2.6, Methodology for the development of data specifications, v3.0,

http://inspire.jrc.ec.europa.eu/reports/ImplementingRules/DataSpecifications/D2.6_v3.0.pdf

[DS-D2.7] INSPIRE DS-D2.7, Guidelines for the encoding of spatial data, v3.2,

http://inspire.jrc.ec.europa.eu/documents/Data_Specifications/D2.7_v3.2.pdf [ISO 19101] EN ISO 19101:2005 Geographic information – Reference model (ISO 19101:2002) [ISO 19103] ISO/TS 19103:2005, Geographic information – Conceptual schema language [ISO 19107] EN ISO 19107:2005, Geographic information – Spatial schema (ISO 19107:2003) [ISO 19108] EN ISO 19108:2005 Geographic information - Temporal schema (ISO 19108:2002)



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

[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 19135] EN ISO 19135:2007 Geographic information – Procedures for item registration (ISO

19135:2005) [ISO 19139] ISO/TS 19139:2007, Geographic information – Metadata – XML schema implementation [ISO 19157] ISO/DIS 19157, Geographic information – Data quality [OGC 06-103r3] Implementation Specification for Geographic Information - Simple feature access –

Part 1: Common Architecture v1.2.0



Annex A (normative)

Abstract Test Suite

Any dataset conforming to this INSPIRE data specification shall meet all requirements specified in this document.

Open issue 8: Conformance testing is still an open issue under discussion.

Instructions on conformance testing and a common abstract test suite (including detailed instructions on how to test specific requirements) will be added at a later stage.



Annex B (informative) Use cases

The use cases presented below are based on real applications, investigated by TWG BU but are projected in future, once INSPIRE conformant data is available. Building data is used in a similar way by different application domains. This is addressed in chapter B1. Domain-specific applications are addressed in following chapters B2, B3 …. The description of the use case is kept short and focuses on the role of building data; it does not aim to provide exhaustive explanations about the use case. The information required by the use cases and provided from INSPIRE theme BU is highlighted in green. Information provided from other themes is highlighted in orange. The purpose of this annex is to show the use cases that have been considered by TWG BU. It provides the rationale of the data specifications and guidelines about how INSPIRE conformant data might/should be used.

11 Common use of building data

11.1 Modelling of physical phenomena Part 1: UML use case diagram

uc Modelling of physical phenomena

Universities, research

Modelling of physical

phenomena

Local governments

Urban planners

Spatial planning agencies

European Stakeholders

European Environmental

Agency

European Spatial Agency

National/local environmental

agencies Use Figure n° 84: use case diagram for modelling of physical phenomena

Part 2: Narrative explanation of the use case Buildings may influence the propagation of physical phenomena, such as air circulation (air pollution, winds), light, water (flood), noise … Data about buildings will be necessary as input for propagation models.



Figure n° 85: principle of propagation model

Figure n° 86: Extract of fire forecast on Europe (EFFIS)

Part 3: Detailed, structured description of the use case Use Case Description

Name Modelling of physical phenomena

Priority high

Description The purpose is to estimate the extent of a physical phenomena, taking into account the influence of buildings on the propagation of the phenomena

Pre-condition

Data related to physical phenomena is available (e.g. hydrography for flood, atmospheric conditions for air circulation). Other necessary topographic data is available (e.g. elevation). A propagation model exists, either as an automatic tool or as a well-defined methodology.

Flow of Events – Basic Path

Step 1. Download INSPIRE topographic data (mainly themes BU, EL) and themes related to physical phenomena (e.g. MF, AC, TN, HY, …)

Step 2

Make a 3D model of landscape using elevation data, preferably as DTM and 3D solid geometry of buildings. Environmental barriers (e.g. dam or embankment for flood, tunnels or acoustic fence for noise, protectiveStructure for rock falling) have to be integrated to this model

Step 3 Possibly, enrich the 3D model by information related to the architecture of the building, such as material of roof / structure /façade, height or number of floors below ground … which may influence the propagation of physical phenomena



Use Case Description

Step 4. The landscape 3D model is supplied as input in the propagation model. The propagation model runs and provides the extend of physical phenomena at a given time

Flow of Events – Alternative Paths

Step 2 bis.

The 3D model may be computed using the polygon geometry of buildings and their height above ground or number of floor above ground or floor distribution If available, the 3D model may use shape of roof to refine the 3D representation of buildings

Step 3 bis If not available, the information related to the architecture of building may be roughly assessed from temporal attributes, date of construction and date of renovation. Domain expertise is required.

11.2 Computation of population in an area of interest Part 1: UML use case diagram

pkg Computation of population

:Eurostat

:Local governments

:National/local environmental

agencies

Computation of population


National statistical agencies

Figure n° 87: use case diagram for computation of population

Part 2: Narrative explanation of the use case Statistical data, such as number and characteristics of inhabitants, are available on statistic units. However, many applications require getting an assessment of the number of inhabitants, not on statistical units, but in the area of interest of the application. Typical example is the necessity to assess and report population at day and/or at night located in an area of risk (flood, forest fire, earthquake …) or of pollution (noise, air pollution). It is also necessary to assess the number of inhabitants that will benefit from a new public equipment; for instance, when implementing a new line of public transport, it will be of great interest to estimate how many people are located near the new transport stops.

Statistical data on statistical units Statistical data on area of interest

Figure n° 88: principle of computation of population in an area of interest Part 3: Detailed, structured description of the use case



11.2.1 Assessment of population at night


Name Assessment of population at night

Priority high

Description The purpose is to estimate the number of inhabitants during night in an area of interest, for instance an area concerned by noise or air pollution.

Pre-condition The area of interest is known. Statistical data on population are available on statistical units.


Step 1. Download INSPIRE themes BU and SU - PD

Step 2 Within the area of interest, using attribute current use, select residential buildings. These are the buildings where most people are located at night.

Step 3

Compute the total area of each building dedicated to residential purpose:

- from polygon geometry, compute ground area - total area = ground area x number of floors x percentage of

residential use (if known)

Step 4. For each statistical unit, compute the total area of all buildings

Step 5 Compute the number of inhabitants in each building Number of inhabitant (building X) = (number of inhabitants (SU)/ total area of all buildings in SU) x total area of the building

Step 6. Add the number of inhabitants of all buildings located in the area of interest. This number assesses the population at night.


Step 3 bis. The total area of each building may be assessed by different ways:

- the number of floors may be assessed from the height above ground

- if available, the official area may be used

Step 3 ter In case the percentage of current use is unknown, the use case will use total area instead of total area dedicated to residential purpose..

Step 3 quatro. Instead of the total area of building, the computation may be done using the volume of building. This volume may be supplied by ground area (from polygon geometry) x height above ground

Result The assessment of population at night is used to implement local management (e.g. schedule rescue services at night) or for reporting (e.g. noise or air pollution)

Data source: <Name> [repeat per data source]

Description INSPIRE themes SU, PD, BU

Geographic scope Area of interest, anywhere in Europe

11.2.2 Assessing population at day


Name Assessment of population at day

Priority high




Description The purpose is to estimate the number of inhabitants during day in an area of interest.

Pre-condition The area of interest is known. Statistical data on population are available on statistical units. Some domain expertise is required.


Step 1. Download INSPIRE themes BU, US and SU - PD

Step 2

Assess population in residential buildings. The method is similar to the method described in B1.2.1 but the number of inhabitants has to be replaced by the number of inhabitants staying at home. It is up to domain expertise to decide which method is better:

- apply a percentage - restrict the number of inhabitants according to selection criteria

(age, type of job, …) It may also vary according hours in the day.

Step 3

Assess population in industrial or buildings. Using attribute current Use, select industrial buildings. Compute total area of industrial buildings (same method as for residential buildings). Apply an average rate of occupation to assess the number of people within industrial buildings.

Step 4.

Assess population in office buildings. Using attribute current Use, select office buildings. Compute total area of office buildings (same method as for residential buildings). Apply an average rate of occupation (e.g. 4 persons / 100 m2) to assess the number of people within office buildings.

Step 5

Assess population in commercial buildings. Using attribute current Use, select trade buildings. Compute total area of industrial buildings (same method as for residential buildings). Apply an average rate of occupation to assess the number of people within office buildings.

Step 6.

Assess population in public services. This may be done using attribute occupancy of Governmental services in theme US. Using attribute service hours, the information may be refined according day in the week and/or hour in the day.


Step 3 bis Download data from theme PF. Information about the activity hosted by the buildings within a PF may enable domain expert to make more detailed assessment of the number of occupants the industrial buildings.

Step 3, 4, 5 bis.

A local or national information system on economic activities exist and may be linked to their location in buildings, using :

- common address - or the attribute external reference of theme BU

The knowledge of activity enable domain expert to make more detailed assessment of the number of occupants in a commercial, industrial or office building.

Result The assessment of population at night is used to implement local management (e.g. schedule rescue services at day, assess need of public transport) or for reporting (e.g. noise or air pollution).


Description INSPIRE themes SU, US, PF, PD, BU, AD




Geographic scope Area of interest, anywhere in Europe

11.3 Large scale 2D mapping Part 1: UML use case diagram

uc 2D maps

Large scale 2D maps

Local governments


National mapping agencies

Tourism offices

Utility managersTransport managers

Environmental agencies

Rescue services

Institutions for Cultural Heritage

Preservation

City visitors

Citizens

Figure n° 89: use case diagram for large scale 2D mapping

Part 2: Narrative explanation of the use case Mapping of urban areas at large scale is one of the common requirements of most use cases. Large scale maps are necessary or at least very useful for a lot of applications, e.g.

- ordinary city maps to help any city visitor (tourism, business, conferences, …) to discover the urban area and to find his/her way to the main places of interest or to a given address

- documents to prepare decision making, showing the issue to be solved in its environment - communication documents to make people aware of a specific aspect of the urban area (risk

area, polluted area, …) - working documents to help the operational staff that has to ensure in a way or another the

management of the urban area Of course, these different kinds of mapping have some specificities, according to the purpose of the map; only the part that is (likely) common to all of them is described below. Note that, in this common use case, urban area should be understood with a wide meaning, as mapping is, of course, also of interest for villages. Part 3: Detailed, structured description of the use case Use Case Description

Name Large scale 2D mapping

Priority high

Description The purpose is to make 2D maps for target users.

Pre-condition Necessary data is available:

- at least TN, BU, US - and possibly AU, CP, AD, HY, GN





Step 1. Download the INSPIRE themes

Step 2

Select the following features and represent them using their geometry: - roads by lines - buildings (and possibly building parts) by 2D polygon - constructions by polygons, points or lines - governmental service geometry (as point or surface) - administrative boundaries and administrative units - cadastral parcels by surfaces - address (by points) - ….

Step 3

Choose relevant portrayal for selected features. For instance, portrayal rules may give different styles according to the value of an attribute, e.g.:

- for roads, the Form Of Way or the Functional Road Class - for buildings, the building nature - for other constructions, the construction nature - for administrative boundaries, the boundary level - for governmental services, the service Type

Buildings with specific interest and constructions together with governmental services are necessary because they are both useful landmarks and potential places of interest.

Step 4.

Place the writings associated with each feature, e.g. - road name - label for Cadastral parcels - locator designator for addresses - name for buildings and constructions - name for governmental services

Step 5 Complete the map by giving legend, scale, …

Step 6. Make the map available to its target (e.g. as paper map or on Web site)

Result A city map is available for the targeted users.


Description INSPIRE themes at least TN, BU, US and possibly AU, CP, AD, HY, GN

Geographic scope Urban areas, everywhere in Europe

11.4 Deriving medium scale data Part 1: UML use case diagram



uc Deriv ing medium scale data

Deriving medium scale data

Local governments

National mapping agency

EEA (European Environmental

Agency)

National/local environmental

agencies

Rescue services

Tourism offices

Tourists, travellers

Citizens


Preservation

Figure n° 89 : use case diagram for deriving medium scale data

Part 2: Narrative explanation of the use case The general purpose is to analyse the structure of an urbanised area. For instance, to get an overview of the city, it is often necessary to make maps of it, at smaller scales than the scales used for reference data, such as buildings. Typically, whereas it is meaningful to represent buildings at scales most detailed than 1/ 20 000, city maps at less detailed scales, such as 1/ 50 000 and 1/ 100 000 are also needed. For producing these maps and for enabling spatial analysis at the city scale, it is necessary to derive urban and urbanised areas from source topographic data. This is done by making relevant groupings of buildings (sometimes, also called blocks) and to provide urban areas of homogeneous type; the building blocks are generally defined by gathering buildings that are close to one another and that share some common characteristics. For instance, it will be meaningful to make groups of individual houses and groups of industrial buildings. The medium scale mapping use case addresses applications such as generalisation of topographic maps and the derivation of land use or land cover maps from most detailed topographic data. 1:10k

1:50k

1:100k

Figure n° 90: Example: Swiss topo maps

Part 3: Detailed, structured description of the use case




Name Medium scale mapping

Priority high

Description The purpose is to make medium scale maps in urban areas.

Pre-condition Topographic data is available. Specifications of the medium scale map are defined.


Step 1. Download INSPIRE topographic themes, mainly BU, US , TN and HY

Step 2 The specification of medium scale map gives the classification of the urban or urbanised areas to be defined (e.g. individual residential areas, industrial areas, …) and the target scale.

Step 3

Automatic or semi-automatic generalisation rules to transform buildings into different kinds of urban areas are elaborated, based on:

- the target classification and scale - the content of source data (see step 4)

These generalisation rules use mainly - the proximity of buildings (e.g. maximum distance from one

another, no big roads between them) - common properties (e.g. individual houses, industrial buildings,

…) Other constructions may also have to be grouped to define urbanised areas.

Step 4

The relevant attributes to be used by the generalisation rules are identified , for instance:

- 2D geometry to make computation of distance from one building to another or to compute buffers around buildings

- if available, current use of buildings to make difference between collective/individual residential areas, industrial areas, …

Attributes service type, construction nature and building nature may help to refine the classification From the 2D geometry, the size, orientation, elongation, compactness of the buildings may be computed. The height above ground or number of floors above ground may help to distinguish between individual and collective residential purpose if this information is not available from current use. The geometry and importance of roads, railways, watercourse is necessary to ensure continuous urban areas.

Step 5. The generalisation rules are run on source topographic data. Urban/urbanised areas are known by their geometry and classification.


Step 1 bis Download also theme OI

Step 3 bis

The derivation is not done by automatic rules but the urban or urbanised areas are delimited and classified by human beings. Instead of defining generalisation rules, data capture rules are defined based both on the characteristics of buildings, constructions, transport, … (as in step 4) and of the ortho-image

Step 5 bis The capture rules are applied on source topographic data and on ortho-image. Urban/urbanised areas are known by their geometry and classification.

Result A medium scale map with target scale and classification of urban areas is available. It may be part of a LU or LC data set.





Description INSPIRE themes BU, US, TN, HY (and possibly OI)

Geographic scope Any urban area in Europe

11.5 3D models Part 1: UML use case diagram

uc 3D models

3D modelsCitizens

Local governments

Rescue services

Tourism offices


Preservation

Risk managersSpatial planning agencies

Construction companies

Tourists

Figure n° 91: use case diagram for 3D models

Part 2: Narrative explanation of the use case 3D models are becoming more or more usual for management of territory. They are used mainly for two purposes: construction projects and communication. 3D models are currently used in case of a project for a new public infrastructure. In this case, the 3D model helps to realize how the new infrastructure will be inserted in its environment, it helps deciders to choose between different proposals, it enables good communication with citizens. 3D models are also quite useful to make the studies about heat or noise propagation. Accurate 3D models are required. There is also a growing trend to deliver building permits to private projects, based on requests including 3D models. 3D models are also a fantastic tool for communication, e.g.

- for making people more conscious of risk (showing a risk zone in a 3D model) - advertising for a territory, to encourage tourists to visit it or companies to set up their business

or just to enable citizens to have better knowledge of their environment.



Figure n° 92: Project of a new motorway and new neighbourhoods


Name Use of 3D models

Priority medium

Description A local government uses a 3D model for a construction project for a new infrastructure and for related communication

Pre-condition


Step 1. Download INSPIRE theme BU with 3D profile

Step 2 If necessary, enrich the 3D profile. Typically, a more detailed description may be required for the noticeable buildings or for the buildings in the area of interest

Step 3 Potential construction companies are invited to present their proposals by showing the new infrastructure plan within the 3D model, showing the 3D geometry of previous buildings.

Step 4. Technical studies (noise, energy, visibility, vulnerability) are carried out taking into account the position of walls, roof, openings (doors and windows) and the material of roof, material of façade, material of structure…

Step 5 The proposals from construction companies will be shown to deciders and to citizens. Textures close to real-world appearance will help people to get better understanding of the project and to provide relevant feed-back and decisions

Step 6 A proposal is chosen. In case the new infrastructure is itself a building, its own 3D model may be linked through external reference to the PLM (Project Lifecycle Management) documents.

Step 7 The enrichments of 3D model + new infrastructure 3D representation may be published for INSPIRE under the 3D profile.


Step 1 bis

Download theme BU with 2D profile. Make 3D representation of buildings by extruding the 2D geometry using height above ground or number of floor above ground or better floor distribution. Typical textures might be guessed from material of roof and material of facade.




Result The new infrastructure has been designed and chosen in a way ensuring a good integration in its environment. The enrichments to the 3D model are available to other users.

12 Safety

12.1 Travel security Part 1: UML use case diagram

uc Trav el safety

Travel security

Travellers

NavigatorsAviators

ICAO (International Civil

Aviation Organization)

Civil Aviation Services National

Hydrographic organisations

IHO (International Hydrographic Organisation)

Public Transport Offices

Rescue servicesLocal

governments

Figure n° 93: use case diagram for travel security

Part 2: Narrative explanation of the use case Building data is necessary to ensure safe travel both for air navigation (where buildings and other constructions are obstacles and so, as dangers for flights) and for marine navigation (where buildings and other constructions may be used as landmarks and so as helps for navigators). More generally, buildings and constructions having a specific physical aspect constitute landmarks and are useful for any kind of travelling. The requirement for data harmonisation coming from marine and air navigation is quite strong and these two communities have adopted international standards:

- 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. The case of marine navigation is provided more in detail below but the case of air navigation is quite similar. Hydrographic Organisations have the mission to ensure safety of sea navigation by producing marine charts. These marine charts include navigation aids, bathymetry … They are provided to navigators either through paper charts or through ENC (Electronic Navigation Chart). The specification of Navigation Electronic Chart has been developed by IHO (International Hydrographic Organisation).



Standardised symbols for marine charts Extract of marine chart Figure n° 94 : marine charts



Name Updating of Electronic Navigation Charts using INSPIRE building data

Priority high

Description The envisaged scenario is that a Hydrographic Organisation uses INSPIRE data as warnings to update Electronic Navigation Charts (ENC)

Pre-condition Specifications of Electronic Navigation Charts are available.


Step 1. Download the evolutions of INSPIRE data (themes BU, US, TN), using queries based on temporal attributes in the data set

- beginLifespanVersion (to get new features) - endLifespanVersion (to get old features)

Step 2

Select the new buildings and other constructions that may be of interest for marine navigation (those easy to be recognized). These queries may be done using attributes constructionNature, buildingNature, heightAboveGround The query will provide features such as chimneys, antennas, stadium, towers, churches, mosques, tanks, silos, windmills, wind turbines

Step 3

Select the new governmental services that may be of interest for marine navigation (e.g. hospital, education) by a query on attribute serviceType. Select the features of interest in theme Transport Network (e.g. raiwayStation).

Step 4 For the selected features, take in the INSPIRE data sets (if available) the information required by ENC specification: 2D geometry, elevation, heightAboveGround, name

Step 5

For the selected features, provide their classification according to ENC specification:

- some values may be taken directly from theme BU (buildingNature and constructionNature)

- some values come from theme US (serviceType) and have to be reported on theme BU (e.g. by using geometry overlay)

- some values may have to re defined with more details (e.g. monument into column, obelisk …).

Step 6 For selected features, add missing information according ordinary update procedures (e.g. computation of a symbol )

Step 7 Make comparison between Electronic Navigation Chart and INSPIRE old objects, using 2D geometry. Delete the ENC features corresponding to old INSPIRE features




Step 8 The Hydrographic Organisation may then publish updated data under INSPIRE specifications (possibly using the possibility to extend code lists of buildingNature and constructionNature). The enriched data is available for other users.


Step 4 bis.

The elevation is supplied by theme BU but not in the vertical Reference System used by the marine community. The elevation may be provided in another Vertical Reference System, under condition that the Elevation Reference System is well documented.

Result The INSPIRE BU and US data have helped Hydrographic Organisation to update Electronic Navigation Charts.


Description INSPIRE themes BU, US

Geographic scope Along sea coastlines

12.2 Risk assessment Part 1: UML use case diagram

uc Safety

Risk assessment

Energy supplier

Risk managersCivil protectionRescue services

European Environmental

Agency

Local governments

Utility supplier Insurance companies

Citizens

European Commission

Universities, researchers

Economic actors

Environmental agencies

Local/national public bodies


Preservation


f Figure n° 95: use case diagram for risk assessment

Part 2: Narrative explanation of the use case There are many sources of potential risk and assessment of the risk impact is the first step necessary to take relevant protection and rescue measures.

• For instance, the EU Floods Directive (2007/60/EC) Directive requires Member States to assess if all water courses and coast lines are at risk from flooding, to map the flood extent



and assets and humans at risk in these areas and to take adequate and coordinated measures to reduce this flood risk.

• Earth quake is potentially the most significant risk as it may cause thousands of death. Some

parts of Europe are subject to earthquake risk.

Figure n° 96: assessment of earthquake risk

• In opposite to other continents, Europe is not frequently victim of wind storms. However, this risk also occurs, as shown by the 1999 wind storm. Moreover, some Member states have over-sea territories which may suffer from frequent wind storms.

• Landslides are various types of gravitational mass movements of the Earth’s surface.

‘‘Landslides’’ are a complex-disaster phenomenon triggered by earthquakes, heavy rainfall (typhoons, hurricanes), sustained rainfall, volcanic eruptions and heavy snowmelt, unregulated anthropogenic development, mining, tunnelling and others. Landslides cause many deaths and injuries and great economic loss to society by destroying buildings, roads, life lines and other infrastructures; they also pose irrecoverable damage to our cultural and natural heritage. Large and small landslides occur almost every year in nearly all regions of the world. Large-scale coastal or marine landslides are known to cause tsunami waves that kill many people. Landslides also may occur just due to progress of natural weathering; therefore, they occur almost everywhere in the world. Landslides most commonly impact residents living on and around slopes.

• The European Forest Fire Information System (EFFIS) has been established by the Joint

Research Centre (JRC) and the Directorate General for Environment (DG ENV) of the European Commission (EC) to support the services in charge of the protection of forests against fires in the EU and neighbour countries, and also to provide the EC services and the European Parliament with information on forest fires in Europe. EFFIS addresses forest fires in Europe in a comprehensive way, providing EU level assessments from pre-fire to post-fire phases, thus supporting fire prevention, preparedness, fire fighting and post-fire evaluations.

Although risk assessment it is not always a mandatory task with a legal framework, it is a main component in the disaster management cycle. Moreover, the Solvency Directive aims to ensure that insurance and reinsurance companies have enough funding to be able to reimburse the losses due to hazards. Part 3: Detailed, structured description of the use case


Name Assessment of risk

Priority high




Description The purpose is to estimate the impact of a potential risk

Pre-condition The risk zone has been delimited. In case of natural risk, theme NZ is available.


Step 1. Download INSPIRE theme BU, US, PF, AF TN, … Download theme NZ or use delimitation of human risk (e.g. around a SEVESO site)

Step 2 Based on their 2D geometry, select the features (BU, US, TN, …) located in the risk area.

Step 3

Assess the general vulnerability of the risk area. Typically, identify if infrastructures that are essential for the community (such as water / power / telecommunication supply, hospitals, rescue services) are in the risk area. This may be done using attribute service type of governmental services.

Step 4

In the area of risk, assess the vulnerability of the buildings, e.g. using attributes:

- material of structure for fire or earthquake risk - number of floors, floor description (with area of openings)

for flood risk and earthquake - material of façade, material of structure for industrial risk

According to the results, some buildings may be excluded for a given level of risk. In opposite, some buildings may be identified as more vulnerable than the average, generally based on the height above ground or number of floors (e.g. a low building for flood, a high building for most of other risks) or material of structure (e.g temporary habitat such as mobile homes may be more vulnerable to any risk)

Step 5 In the area of risk, make assessment of the population at night and of the population at day (see common use cases B1.2.1 and B1.2.2)

Step 6

In the area of risk, assess the value of properties. For buildings, this may be done by applying average prices (e.g. by cost/ m2 in a neighbourhood) using the geometry of building and its total area (official area or area derived from geometry x number of floors) The value of furniture can not, a priori, be assessed from INSPIRE data.


Step 4 bis. If relevant attributes to assess vulnerability are not available, a rough guess may be done using date of construction and date of renovation. This requires domain expertise.

Step 4 ter

If relevant attributes to assess vulnerability are not available, it may be possible to get them using mechanisms to have access to more detailed information:

- external reference to other information system - document (e.g. building permits, building code, …)

Step 6 bis If available, the official value may be used to refine the assessment of the value of the building property.

Result The impact of risk is assessed and may be reported, if required by a European Directive (e.g. Flood Directive)


Description INSPIRE themes BU, US, PF, AF, TN ….

Geographic scope Risk areas in Europe



12.3 Risk management Part 1: UML use case diagram

uc Risk management

Risk management

Civil protection

Rescue services Citizens

Ministry of Interior Local/national governments

Figure n° 97: use case diagram for risk management

Part 2: Narrative explanation of the use case National and local governments have the responsibility to ensure safety of citizens. They are in charge of risk management, i.e. of the actions to reduce as much as possible the risk and to organise the rescue of people when the risk occurs.

Figure n°98: Buildings in a flooded area



Name Management of risk

Priority high

Description The purpose is to manage the risk, in order to decrease its consequences

Pre-condition The risk has been (more or less) identified, delimited and assessed


Step 1. Download INSPIRE theme NZ, BU, US, PF, AF TN, HY, …

Step 2

Check if the environmental barriers (e.g. embankments, dam, …) are adapted to the risk. If not, improve these environmental barriers or build new ones. Attributes such as height above ground and year of construction will contribute to this checking.




Step 3

Make people aware of the risk by publishing risk maps (see common use case B1.3). A 3D representation, using 3D geometry, may be more efficient to make people conscious of the risk and so, to make them ready to follow the advices for reducing risk and/or how to act in case of emergency.

Step 4 When possible, based on the assessment of vulnerability, encourage people to decrease the vulnerability of their buildings to risk (e.g. making buildings stronger to resist avalanches or explosions).

Step 5 a

Schedule in advance the rescue operations, e.g. - based on the results of assessment of population at day and at

night, schedule the number of vehicles necessary in case of evacuation

- schedule the possible itineraries from rescue service to potential risk areas. Identify key infrastructures, such as bridges and tunnels, check how they may be affected by the risk, using attributes such as height above ground and year of construction.

Step 5 b

Identify the buildings and governmental services that may be resource in case of risk, e.g.:

• schools, sport infrastructure for emergency shelters (with attribute service type)

• open air spaces to gather people • open air pools in case of fire risk • buildings with flat roof for helicopter landing (attribute

roof type) • self-sustainable buildings with installations such as

wind turbine or solar panels

Step 5 c

Based on the assessment of vulnerability - identify the buildings and governmental services to be rescued

first: e.g. informal settlements and mobile homes (from attribute material of structure) are very vulnerable to flood

- schedule emergency interventions for the buildings with higher risks (e.g. buildings receiving public, very high buildings). Detailed data related to these very risky buildings may be linked to the INSPIRE data using the external reference or the document attribute.

Step 5 d

Rescue services will need to find the building associated to an address; detailed 3D geometry (ideally with description of openings, of internal and external installations such as stairs, lifts and with description of building interior for the largest buildings: rooms and/or building units) will be useful for emergency interventions.

Result The risk is managed and its consequences are reduced, as much as possible.


Description INSPIRE themes NZ, BU, US, PF, AF, TN ….

Geographic scope Everywhere in Europe

NOTE: risk management may apply to natural risks but also to any kind of risks.



13 Urban expansion

13.1 Integrated urban monitoring Part 1: UML use case diagram

uc Urban expansion

Integrated urban monitoring

Local governments

Citizens

EEA (European Environmental

Agency)



Sustainable development

agencies

Figure n° 99: use case diagram for integrated urban monitoring, urban atlas and INSPIRE land use

Part 2: Narrative explanation of the use case Urban areas increasingly use resources from abroad, impacting on areas far away, and thus become more and more dependent on remote areas influencing also their resilience. These factors, as well as demography and lifestyles, change the metabolism regarding intensities, distribution, dependencies and resilience. The purpose is to develop a conceptual framework to capture urban metabolism in Europe, which can adequately describe the functionalities, assess the environmental impacts of urban areas/patterns as well as ongoing urbanisation processes across Europe, show the inter-linkages and mutual impacts among urban areas and between urban and rural areas, and identify the drivers and successful response measures. The concept of Urban Metabolism goes back to Abel Wolman (1965), who was the first to draw the comparison between an organism and a city. Cities, like organisms, need energy and resources such as fuel, water or food as inputs to sustain life. These ‘metabolic inputs’ are processed and ultimately released back to the environment as wastes. Hence, the basic rationale behind the urban metabolism concept is that the relationship between the environment and an urban system can be described by systematically recording all flows to and from the environment in physical terms in analogy to economy-wide material flow accounting (Eurostat 2001). In the absence of further information about environmental sources and sinks, this is then usually regarded as an estimate of the pressure environmental pressures generated by urban systems.

13.1.1 Urban Atlas Part 2: Narrative explanation of the use case One of the key questions for urban metabolism research is how trends in urban metabolic flows are linked to trends in spatial structure, urban organizations and lifestyles. An approach has been presented whereby urban flow indicators represent the physical metabolism of a city. Four dimensions are being addressed: energy & climate change, water, waste, land-use. Land-use data can be taken from the Urban Atlas project, where data has already been compiled for larger urban zones with more than 100 000 inhabitants as defined for the urban audit.



Figure n° 100: Urban Atlas Madrid



Name Extending or updating Urban Atlas

Priority medium

Description This use case applies in the case of an update of Urban Atlas or an extension of Urban Atlas to smaller cities is ordered.

Pre-condition Topographic data (including buildings) and ortho-image are available.


Step 1. Download INSPIRE topographic themes, mainly OI, BU, US , PF , AF TN and HY

Step 2

This use case is based on the common use case B1.4 Deriving medium scale data in the alternative path of human capture. In this case, buildings are used as auxiliary data for capturing the land use / land cover areas specified by Urban Atlas, main souce being ortho-image.

Step 3

Some buildings may be automatically classified into a land use / land cover area, by following the data capture rules specified by Urban atlas, e.g. :

• site of industrial activity, energy plants, water treatment plants, sewage plants, farming industries, antennas, … => industrial, commercial, public, military and private units

• schools, universities, hospitals, churches, mosques, temples, chapels, synagogues, penitentiaries, administration buildings, military areas, castles (if not residential) => Public, military and private services not related to the transport system

• dams, protectiveStructure, bunkers, city walls, retaining walls (protecting walls) => Civil protection and supply infrastructure

• acoustic fence (noise barriers), rest areas => Road and Rail network and associated land

• golf courses, amusement parks, sport fields, …=> Sports and leisure facilities

Result A new version or an extended version of Urban atlas is available and may be used to report






13.1.2 INSPIRE Land Use INSPIRE TWG LU has defined a harmonised classification of land use, applicable by all MS in Europe. At short term, many land use data producers will transform existing land use data sets into the INSPIRE model. At long term, INSPIRE land use map might be carried out directly from other INSPIRE themes, by generalisation. For instance, in urban areas, INSPIRE building data might be used to define some of the possible values of the INSPIRE land use classification.

Figure n° 101: Principles of INSPIRE land use classification



Name Producing part of INSPIRE Land Use data

Priority medium

Description This use case applies in the case of a urban planner or local government deriving INSPIRE land use data from topographic data

Pre-condition Topographic data (including buildings) and ortho-image are available.


Step 1. Download INSPIRE topographic themes, mainly OI, BU, US , PF , AF TN and HY

Step 2 This use case is based on the common use case B1.4 Deriving medium scale data in the alternative path of human capture. The target model is the land use model specified by INSPIRE TWG LU,

Step 3

Buildings having attribute current Use with value industrial may be classified under class B Secondary production: Industrial and manufacturing areas Refinement of LU classification may be done using the attributes from PF

Step 4

Buildings having attribute current Use with value commercesAndServices may be classified under class C Tertiary production: Services Refinement of LU classification may be done using the attribute serviceType from US




Step 5

Buildings having attribute current Use with value residential may be classified under class E Residential areas The sub-classification of residential buildings (individual/collective/for communities), the height or number of floors, the number of dwellings may enable to refine the LU classification: - E1 Single house areas - E2 Medium dense residential area - E3 Dense residential area (blocks of flats) - E4 Residential with compatible activity

Step 6 Buildings and Other Constructions having attribute conditionOfConstruction with value declined or ruins or demolished may be classified under F1 Abandoned areas

Step 7 Buildings and Other Constructions having attribute conditionOfConstruction with value underConstruction may be classified under F3 Transitional areas

Result Part of INSPIRE Land use data is available.




13.1.3 Urban metabolism Some of the indicators used to monitor the urban metabolism are related to land use and to buildings

Figure n° 102: A pragmatic indicator framework for quantifying urban metabolism.


Name Report indicators related to urban metabolism

Priority high




Description The purpose is to use building data to report indicators related to urban metabolism

Pre-condition The indicators of urban metabolism are adopted.


Step 1. Download INSPIRE BU, US , SU, PD themes on the area of interest (a priori, city with more than 100 000 inhabitants)

Step 2 Report about building stocks: count the buildings included in the city.

Step 3 Based on the attribute number of dwellings, summarise the number of dwellings included in the city. Report about it.

Step 4 Report about proportion of residents exposed to noise at day, see common use case B1.2.2 (population at day) and the noise use case.

Step 5 Report about proportion of residents exposed to noise at night, see common use case B1.2.1 (population at night) and the noise use case.

Step 6 The report about the proportion of dwellings connected to potable drinking systems may be done, using the external reference to cadastral/official register of buildings where this information may be available in some countries.

Step 7

The report about average area of living accommodation, using: • the total area of buildings devoted to residential purpose

(e.g. area derived from 2D geometry x number of floor x percentage of residential current use)

• the population of the city Alternative steps

Step3 bis In case the number of dwellings is not available, a rough estimation may be done using attributes current use (with value residential) and numberOfBuildingUnits

Result The indicators related to urban metabolism that involve building data have been computed and may be supplied to EEA


Description INSPIRE themes BU, US, SU, PD

Geographic scope Currently, cities of more than 100 000 inhabitants (where Urban Atlas is available)

NOTE: urban patterns indicators (complexity, centrality, compactness, porosity) will likely be computed from Urban Atlas data (land use / land cover).

13.2 Urban planning Part 1: UML use case diagram



uc Urban planning

Urban planning

Local governments

Citizens




agencies

Owners

Figure n° 103: use case diagram for urban planning

Part 2: Narrative explanation of the use case In whole world, including Europe, a powerful force is at work: cities are spreading, minimising the time and distances between and in-and-out of the cities. This expansion is occurring in a scattered way throughout Europe's countryside: its name is urban sprawl. Furthermore, it is now rightly regarded as one of the major common challenges facing urban Europe today. Urban sprawl threatens the very culture of Europe, as it creates environmental, social and economic impacts for both the cities and countryside of Europe. Moreover, it seriously undermines efforts to meet the global challenge of climate change. For instance, coasts are being urbanised at an accelerating rate, and resident communities are being transformed in order to accommodate these new economies. As a result, our coasts are becoming increasingly intertwined with the hinterland and more dependent on tourism and secondary homes. The aim of spatial planning is to control and decide the city expansion by making planned land use maps of the city. These land use maps define the rights and restrictions to construct in an area and draw the city of tomorrow.

Figure n° 104: Urban fabric evolution data (http://geopensim.ign.fr/)



Figure n° 105: Planned Land Use Map


Name Spatial planning

Priority high

Description The purpose is to make maps of planned land use

Pre-condition Necessary data is available. A current land use map is useful. A politic agreement on the spatial planning objectives has been achieved.


Step 1. Download INSPIRE themes, mainly BU, US , TN , PF, AF and CP

Step 2

In order to understand how the city evolves, it may be useful to represent the city at different dates. The city at a given date T in the past may be reconstituted using the attributes date of construction (by deleting the buildings constructed after T) and date of demolition (by re-integrating the buildings demolished since T)

Step 3

The buildings and facilities / governmental services that generate public easement are identified, e.g.

- protected sites, classified monuments, architectural and urban patrimony - lighthouses - oysters facility - powder shops (Defence-Navy) - military airports - military constructions (forts, …) - tanks (gas, fuel) - cemeteries - stadium (sport installations) - risk installations (e.g. Seveso factories) - radio-electric antennas

Most of them may be found using attributes construction nature, buildingNature, service type. Then, the extend of public easements is defined.




Step 4

Local government decide on a planned use map; the land use areas are generally represented on a background map representing cadastral parcels, existing buildings, transport networks. This planned land use map defines the restrictions of construction for the next years, applying to each parcel.

Step 5.

In order to have a better idea of the consequences of the planned land use map, a 3D model may be done:

- using 3D geometry of existing buildings if available; if not, the volume of buildings may be derived from 2D polygon geometry and height above ground

- for buildings under project or under construction, their 3D geometry may be derived in the same way; the height above ground may have to be searched in the building permit (using attribute document or the external reference mechanism)

- simulated data are used for the new buildings that are allowed by the new spatial planning map.

Result A planned land use map is available and may be published for INSPIRE under LU theme


Description INSPIRE themes BU, US, PF, AF, TN, CP


13.3 Urban monitoring Part 1: UML use case diagram

uc Urban monitoring

Urban monitoring

Local governments

CitizensSpatial planning agencies

Owners

Figure n° 106: use case diagram for urban monitoring

Part 2: Narrative explanation of the use case The purpose of this use case is to ensure that the rules defined by the spatial planning map and by other regulations are respected.



Figure n° 107: Detailed cadastral data for urban monitoring



Name Spatial monitoring

Priority high

Description The purpose is to check if spatial planning decisions (registered in a planned land use map) and other urbanism regulations are respected.

Pre-condition Planned land use map and associated regulations are available. A politic agreement on the spatial planning objectives has been achieved.


Step 1. Download INSPIRE themes, mainly BU, TN and CP

Step 2 When a owner asks permission for a new building through the building permit, check if the building permit is conform to planned land use map and other regulations

Step 3

When the building construction is achieved, there may be a checking done by field survey to control if the building in real world is conform to building in the building permit. The reference INSPIRE data may be updated to take into account this new building, ideally with all the attributes of the extended profile that are available from the building permit.


Step 3 bis.

Once an area is constructed, the INSPIRE building data may be used to carry out more systematic checks, using the attributes:

- 2D geometry (for deriving its size) - height above ground of the building - material of roof, material of façade - official area (to check if the density indicators were respected) - detailed 2D geometry to measure distance to the road or to

the cadastral boundary.




Step 3 ter

Systematic check may be done at city level, several years after the planned land use map was published (date T), by comparing the buildings effectively constructed (selection of building whose construction date is after T) with the areas where buildings were allowed.

Result The decisions taken for spatial planning are respected.


Description INSPIRE themes BU, TN, CP


14 Environment

14.1 Noise Part 1: UML use case diagram

uc Noise assessment

Noise assessment

Local governments

European Environment Agency (EEA)

Universities, research Owners


agencies


Citizens

National/local enviromnental

agencies

Institute for health monitoring

National/local public bodies

Figure n° 108: use case diagram for noise assessment

NOTE: this use case diagram applies to B4.1, B4.2 and B4.3.

Part 2: Narrative explanation of the use case European legislation (Environmental Noise Directive; END) defines obligations to consider the environmental noise and noise sources and appropriate actions to address and manage noise issues within the Member States (MS). The scope of the END Directive (Art.2) defines, that this Directive shall apply to environmental noise to which humans are exposed in particular in built-up areas, in public parks or other quiet areas in an agglomeration, in quiet areas in open country, near schools, hospitals and other noise-sensitive buildings and areas. MS establish competent authorities and bodies for making or approving and collecting noise maps and action plans for agglomerations, major roads, major railways and major airports. These authorities are usually designated at local level and hierarchical level of authorities is usually used to collect data (example: from local level) and report to the EC (example: from national level). MS have to report to the European Commission certain data related to strategic noise maps, action plans, noise control programmes, computation or measurement methods used to provide noise values, estimation of people exposed to noise values, etc.



Figure n° 109: Extract of a noise map around an airport


Name Assessment and reporting for Noise Directive

Priority high

Description The purpose is to assess and report noise indicators, in conformance with Noise Directive.

Pre-condition Data related to noise source (e.g. air traffic, road traffic) is available


Step 1. Download INSPIRE themes, mainly BU, US and TN

Step 2

The noise extend is delimited as explained in common use case B1.1 (Modelling of physical phenomena). Main attributes to be considered are the geometry, the height above ground (that may influence the height at which the noise has to be estimated), the roof type (ideally as 3D geometry), the material or texture of façade (that may enable domain experts to deduce noise insulation).

Step 3

The estimation of dwellings, schools, hospitals exposed to noise is done by selecting the buildings and governmental services located in the noise extend:

- spatial query based on their 2D geometry - semantic query based on service type (for schools, hospitals) - semantic query based on number of dwellings for buildings

Step 3 The estimation of people exposed to noise is done as explained in common use cases B1.2.1 (population at night) and B1.2.2 (population at day)

Step 4

Number of people in dwellings with special insulation + ventilation / air conditioning may be assessed by searching detailed information about insulation, ventilation in official building register or in building permits (using document or external reference attributes) and/or by attribute installation nature (e.g. airDuct, air conditioning unit).

Step 5 (optional) The assessment is done with more details, the floors reached by excessive noise are identified (through the height in floor description). Owners of building units in these floors may receive subsidies to improve insulation.

Result Noise indicators are reported (partly) in conformance to Noise Directive.





Description INSPIRE themes BU, US, CP

Geographic scope Areas around airports and main roads.

Note: it is unsure that INSPIRE BU data will be enough to assess the number of people in dwellings with quiet façade

14.2 Air quality Part 2: Narrative explanation of the use case The European legislation (new Directive 2008/50/EC of the European Parliament and of the Council of 21 May 2008 on ambient air quality and cleaner air for Europe, Council Directive 96/62/EC - Air Quality Framework Directive) require to make yearly reporting (around July – August) about the areas where air quality is bad (proportion of pollutants higher than the authorized ones) and the populations concerned by this bad air quality Assessment of air quality may also be useful for urban expansion (e.g. to avoid building a school in a polluted area) or to organise public transport (to reduce the pollution due to car traffic). Data related to buildings are used for two purposes:

- as input parameters in the model to compute propagation of traffic pollution; repartition of buildings has an impact how the pollutants are disseminated (open streets) or not (canyon streets)

- as basis to estimate the number of people in each air quality area.

Figure n° 110: Air quality mapping – Air quality propagation

Part 3: Detailed, structured description of the use case The air quality use case step by step description is very similar to the noise use case one. See B4.1

14.3 Soil Part 2: Narrative explanation of the use case Soil is essentially a non-renewable resource and a very dynamic system which performs many functions and delivers services vital to human activities and ecosystems survival. Information available suggests that, over recent decades, there has been a significant increase of soil degradation processes, and there is evidence that they will further increase if no action is taken.



The European Commission has prepared a project of Soil Directive. Among other measures, the proposed Directive includes:

- the establishment of a common framework to protect soil on the basis of the principles of preservation of soil functions, prevention of soil degradation, mitigation of its effects, restoration of degraded soils and integration in other sectoral policies.

- Setting up an inventory of contaminated sites, a mechanism for funding the remediation of orphan sites, a soil status report, and establishing a national strategy for remediation of the contaminated sites identified.

Figure n° 111: soil contamination


Name Assessment and reporting for future Soil Directive

Priority medium

Description The purpose is to detect, estimate the extent of the soil pollution and the effect on residents but also to prevent pollution of the groundwater through the polluted soil.

Pre-condition Data related to noise source (e.g. air traffic, road traffic) is available


Step 1. Download INSPIRE themes, mainly BU, PF, AD, SO , CP

Step 2

Maps showing potential contaminated sites are carried out, e.g. in old telephone books, registers etc. to find information about activities and buildings which have had a use that potential produce soil pollution. The polluting activities may be geocoded on a background map, using address of the activity

Step 3

For evaluating the extent of the soil pollution in the ground there is used soil samples, information’s about the current and former activities on the site

and several other data about the buildings. In addition there is sometimes made a physical inspection of the building to look for cracks etc in the house where vapours can get in.




Step 4

Analysis of the possible remediation is done, using following attributes: current use, date of construction, number of floor, roof and wall material, value (in some cases if low valued the building can be demolish to clean the soil more effectively). Height above ground is relevant according to degassing and wind condition. The area may be derived from the 2D geometry of the building or official area may be used. The owner of the building may be found in official register of buildings using the external reference of the Building or BuildingUnit or the association or spatial overlay with cadastral parcels. Information about stairs and chimneys is useful vapours from pollution can be spread through these channels. It may be searched using attribute Document (e.g. sketches of building or building permit) Retired features are necessary to explore which buildings that have been on the site, and what kind of function they had.

Result Inventory of contaminated soils and report about remediation actions is ready to be reported for the future Soil directive


Description INSPIRE themes BU, PF, SO, CP, AD


14.4 Energy / Sustainable buildings Part 1: UML use case diagram

uc Env ironment

Energy consumption assessment - promotion of

sustainable buildings


agencies

European Environment

Agency (EEA)

CitizensOwners

Energy suppliers

Eurostat

Local governments National

statistical institutes

Agencies for sustainable development

Figure n° 112: use case diagram for energy / sustainable buildings

JRC has launched a working Group whose aim is to prepare cross-sectoral policies, standards and regulations related to the construction sector in order to promote the sustainability of buildings during their whole life-cycle. The development of a multi-performance labelling of buildings in terms of safety, health, energy efficiency and sustainability is one of the long-term objectives of this Working Group.



Figure n° 113: Proposed multi-performance labelling of buildings in terms of safety, health, energy efficiency

and sustainability (“Building Efficiency Index”).

However, currently, only the assessment of energy performance is required by an environmental Directive, the Energy Performance of Building Directive.

14.4.1 Applying the Energy Performance of Building Directive Part 2: Narrative explanation of the use case Energy consumption produces emissions of CO2 and so contributes to the greenhouse effect and to the increase of temperatures. Over a decade ago, most countries joined an international treaty -- the United Nations Framework Convention on Climate Change (UNFCCC) -- to begin to consider what can be done to reduce global warming and to cope with whatever temperature increases are inevitable. More recently, a number of nations approved an addition to the treaty: the Kyoto Protocol, which has more powerful (and legally binding) measures. At European level, the Energy Performance of Buildings Directive, (EPBD) requires unique building identification for the buildings certificates. Part 3: Detailed, structured description of the use case Use Case Description

Name Implementing the Energy Performance of Building Directive

Priority high

Description The purpose is to implement the Energy Performance of Building Directive. The Energy Performance of buildings has to be calculated only for new buildings or when a building is rent or sold.

Pre-condition Building data is available


Step 1. Download INSPIRE theme BU, US.

Step 2

Identify the buildings that are under the scope of the Energy Performance of Building Directive, using attributes:

- 2D geometry or official area to get the size of the building (< 50 m2 : no requirement, > 1000 m2 : higher requirements)

- classification of the building (i.e. current use and service type) for possible exclusions (religious buildings, agricultural buildings, industrial sites, workshops)

Step 3

Prepare the evaluation methodology. The calculation method should take into account thermal insulation, heating and air-conditioning installations, application of renewable energy sources, design of the building and temporal aspects (distinction between existing and new buildings, age of building). Number of floors has also influence. This kind of information may be more or less found in INSPIRE data, using for instance date of construction, external reference to official building register or to building permit. It has generally to be completed by field survey.




Step 4

The evaluation of energy performance of building is performed when a building is sold or rent. The owner or the tenant of the building may be found in official register

of buildings using the external reference of the Building or Building Unit or the association or spatial overlay with cadastral parcels.

Step 5 The result of this evaluation may be captured to updated INSPIRE data, under attribute energyPerformance

Result The Energy Performance of Building Directive has been applied; information about energy performance is available for environmental studies.




14.4.2 Promoting reduction of CO2 emissions Part 2: Narrative explanation of the use case Moreover, some Member States or local governments are willing to have more pro-active policy and to encourage citizens to improve heating efficiency of their buildings (by better isolation). Better insulation not only reduces the emissions of greenhouse gazes but also contributes in long-term to money saving for inhabitants and to reduce the energy dependency of European countries.

Figure n° 114: infra-red images showing loss of energy by roof or by façade. Part 3: Detailed, structured description of the use case Use Case Description

Name Promoting the reduction of CO2 emissions by buildings

Priority high

Description The purpose is to assess the energy demand of buildings and/or to detect the houses with heat losses and to encourage owners to make insulation works.

Pre-condition Data related to buildings is available. Domain expertise is required.


Step 1. Download INSPIRE theme BU




Step 2

Assess the energy demand of buildings. Ideally, this should be done using LoD4 representation of buildings with geometric description of building units and detailed information with attributes material of roof, material of façade, heating source, heating system (or by searching information about heating in cadastral register by the external reference) and with feature type installations (air conditioning unit, solar panel, wind turbine). The assessment may be done in a rough way, by using 2D geometry, height above ground or number of floors and by deriving the above information about quality of construction and heating from year of construction and year of renovation

Step 2

Identify the buildings with significant heat losses. This may be done using different methodologies:

- Deriving it from the assessment of energy demand (step2 - using infra-red images to show heat losses by roof (aerial

images) or by façade (images taken from a vehicle in the street)

Step 3

Prepare representations of the results. This may generally be done using the common use case B1.3 (Large scale mapping). Note that to represent the

results of infra-red roof images, the 2D geometry (polygon) of buildings is required, preferably captured by roof edge. To represent the results façade of infra-red images, the 3D geometry of buildings is required.

Step 5

To make inhabitants aware of the results, the resulting map or 3D model may be published on a Web site or an extract may be sent to the owner. The owner of the building may be found in official register of buildings using the external reference of the Building or BuildingUnit or the association or spatial overlay with cadastral parcels.

Step 5 Local or national governments may envisage financial incitation (e.g. tax

reduction) to promote insulation. The cost of this measure may be estimated, based on the previous results

Step 6

Local or national governments are also building owners. In order to show exemplarity, they may be willing to make insulation works in their own patrimony. Analysis of more detailed data (such as 3D geometry with shape of

roofs and openings, images of buildings under document attribute) will help them to make first identification of the insulation works to be done.

Result Building owners are aware of the heat losses and so, may be encouraged to reduce them by insulation works.


Description INSPIRE themes BU


14.4.3 Sun exposure Part 2: Narrative explanation of the use case The aim is to detect buildings on which solar panels may be installed, in order to promote use of renewable energies and to ensure better sustainability of the building. The expected result is maps showing these buildings with good sun exposure. An indicator about sun exposure (number of sunny hours by day) has to be computed. Part 3: Detailed, structured description of the use case


Name Sun exposure

Priority high




Description The purpose is to identify the buildings that are relevant for installation of solar panels on their roof.

Pre-condition Building and elevation data available.


Step 1. Download INSPIRE theme BU, EL, possibly OI

Step 2

Compute the propagation of sun. This may be done as explained under common use case B1.1 modelling of physical phenomena. Ideally, should be done with 3D geometry with shape of roof. However, rough assessment may be done using 2D geometry and height above ground. This computation gives the buildings with good sun exposure.

Step 3

Refine the analysis to identify the roofs that may receive solar panels: - Using the attribute material of roof and/or roof shape,

exclude the buildings that are not appropriate (e.g. covered by thatch)

- Owners are generally reluctant to set solar panels if the building has a roof terrace. An investigation may be done using images of roof (as document) or high-resolution ortho-image

Step 4

An electricity company may want to prospect building owners to propose them installation of solar panel. This may be done by field prospecting. A working map has to be prepared to hep the prospector to find the relevant buildings, as described in common use case B1.3 Large scale mapping.

Result The buildings that may receive solar panels are known.


Description INSPIRE themes BU, EL, possibly OI

Geographic scope Sunny areas in Europe

14.5 Quality of habitat Part 1: UML use case diagram

uc Quality of habitat

Quality of habitat


agencies

European Environment

Agency (EEA)

Citizens

Local governments

Agencies for spatial planning

Health monitoring institutes

Figure n° 115: use case diagram for quality of habitat

Part 2: Narrative explanation of the use case The general purpose is to carry out studies about habitat (e.g. social habitat, unhealthy habitat, urbanism documents) and to make deciders (municipality level) aware of the evolution of their territory. The deciders may then decide of relevant actions, such as launching projects of social habitat or buying public land for potential new projects.



Figure n° 116: Simulation of project, buildings that are going to be demolished are shown in blue Part 3: Detailed, structured description of the use case


Name Quality of habitat

Priority medium

Description The purpose is to assess the quality of habitat in order to take relevant decisions to improve it

Pre-condition Political will to improve quality habitat is required.


Step 1. Download INSPIRE themes BU, US, CP, TN

Step 1

An atlas of built-up area is carried out (see common use case Deriving medium scale data). The atlas helps to identify the density of buildings (e.g. number of dwellings per cadastral parcel) and to see the possibilities of evolution. The official trend is to increase the density in order to reduce ecological costs of transport and land take.

Step 3

An atlas of public services is carried out, based mainly on the geometry, service type and capacity of governmental services. The aim is to increase the accessibility; people should find all they need near their home in order to reduce the economic and ecologic cost of transport.

Step 4 An atlas of commercial activities is carried out, for instance by geocoding an activity file on buildings, using a common address. Accessibility to commerce is a criteria of life quality.

Step 4 An atlas of social habitat is prepared; 2D geometry of buildings is used as background data to locate programmes of social habitat

Step 5

Monitoring of co-ownership properties is done. If a property has significant vacant flats, quick turn-over of owners and big rate of rent, it means that this habitat programme was not successful. This information may be found in the official building register by the external reference. The local government should not reiterate this type of building programme and may also take measures such as subsidies for work in buildings, buying unused dwellings and/or common parts … in order to improve the situation of the unsuccessful co-ownership property.




Step 6

An atlas of precarious/bad condition habitat is carried out. Information about precarious buildings (mobile homes, caravan sites, shelters, ..) is useful. These kind of habitat may also be assessed by using both data about income of population and data related to the building (date of construction, date of renovation, number of dwellings, 2D geometry + number of floors + current use to derive the habitable area). For instance, the number of occupants by dwelling is a good indicator. Presence of comfort elements (toilet, heating, kitchen, water supply) may be found in official cadastral register, using the external reference.

Step 7

An analysis of healthy/unhealthy habitat is conducted, e.g. influence of heat waves, noise, air pollution, radon, risk of lead poisoning. Attributes date of construction, material of roof / façade /structure, heightBelowGround or numberOfFloorsBelowGround (for radon), 3D geometry with openings (for noise and heat propagation) are necessary to conduct this type of analysis.

Step 8

Some buildings are considered as totally inappropriate for habitat; local government decides to demolish them in order to construct more adapted dwellings and/or services. The 3D geometry of building is used for 3D models that enable deciders and citizens to realize the impact of the project.

Result Local governments have a clear idea about the quality of habitat and may take relevant decisions.


Description INSPIRE themes BU, US, TN, CP


14.6 Buildings with historical or architectural interest Part 1: UML use case diagram

uc Env ironment

Buildings with historical or architectural interest

Local governments

Tourists

Universities, researchers

Citizens

Institutions for Cultural

Preservation Heritage

Tourim offices

Figure n°117: use case diagram for buildings with historical or architectural interest

Part 2: Narrative explanation of the use case Europe countries have had a long history and beneficiate of a rich architectural patrimony. The aim of this use case is to share and increase the knowledge about buildings with historical and architectural interest and to make valorisation of this patrimony through communication actions.



Figure n° 118: Mont Saint-Michel (France)


Name Buildings with architectural or historical interest.

Priority medium

Description The purpose is to share and increase the knowledge about buildings with historical and architectural interest and to make valorisation of this patrimony.



Step 1. Download INSPIRE theme BU, US, TN, CP, PF

Step 2 - Scenario 1

Decision to collect the work of various researchers in history and archaeology is taken. Moreover, the results of these researches will be located, using INSPIRE data as background. 2D geometry of buildings is used to locate the historical/architectural buildings

• In case of buildings that still exist, the INSPIRE 2D geometry may be used as it is

• In case of buildings that no longer exist, their geometry may be located using relative distance to current BU, TN, …. It may be represented by a polygon or roughly by a point

Step 2 - Scenario 2

A more ambitious decision is taken: to make inventory of all buildings with historic or architectural interest. INSPIRE data may be used to prepare the field survey by identifying the

areas to be investigated (for instance, it is unlikely that a new suburb area with cheap houses looking like one another deserves to be visited). This first selection may be done using attributes such as year of

construction, condition of construction (ruins), official value, construction nature (monument), building nature (church, chapel, castle), service type (hospital, governmental service, university, …). INSPIRE data is used to make work maps for the field survey, as

described in the common use case B1.3 large scale mapping.

Step 3

The work of researchers or the results of the inventory is structured according to the INSPIRE application schema, using mainly the temporal attributes (condition of construction, date of construction, date of renovation, date of demolition), the possibility to attach documents to a building. The classification of buildings may be done by extending attributes construction nature and building nature or by adding other attributes. The result of this work may be published on a Web site and contributes to enrich the knowledge of the city history.




Step 4

Once the patrimony has been identified, other actions may be conducted to make valorisation of the territory. For instance:

- Maps of the city at different dates may be produced. - The results may be shown on current cadastral plan (interest for

the owners of the parcel) - Walking tours may be organised - Protection measures of the patrimony may be taken

It may also be a motivation for ordering the production of the detailed 3D geometry of these buildings, in order to enrich the web site or brochures of the city.

Result The knowledge about buildings with architectural or historical interest has increased and may be shared by everyone


Description INSPIRE themes BU, US, PF, TN, CP


15 Infrastructures Part 1: UML use case diagram

uc Infrastructure

Infrastructure implementation and

management

Local governments

Construction companies


Utility manager

Citizens


agencies


Figure n° 118: use case diagram for Infrastructure implementation and management

15.1 Location of a new service/activity Part 2: Narrative explanation of the use case Example 1: find better location for new antennas The purpose is to find, for potential new antennas, the buildings reached by this antenna and then, to estimate the percentage of buildings covered /reached by this antenna. Several potential locations for the antenna have been identified. For each of this position, a simulation is done, by making “visibility maps” from the antennas (see common use case B1.1 modelling of physical phenomena). The location that is “visible” by the higher percentage of buildings will be considered as the best one.



Example 2: prove the necessity of a new antenna. A telecommunication company is initiating a project related to implementation of new antennas for mobile phone. The influence area of an antenna depends of the landscape, for two reasons:

- buildings may disturb propagation of phone waves - more antennas are needed in urban areas to be able to deal with more calls

For instance, in rural areas, the antenna impact varies from 2 km to 35 km. In urban areas, the antenna impact may be smaller than 500 m. As there are doubts about influence of phone antennas on health, the telecommunication company has to give rationale for implementation of a new antenna and must prove that there are requirements to get permission from local governments. So, the telecommunication company need to determine the characteristics of the area around the new antenna. For instance, the need for mobile phone is bigger in large business areas than in residential areas. The density of buildings is also a significant criteria. There is socio-economic data on statistical units but building data is required for more accurate spatial location of this information (see common use case B1.2.2 Computation of population at day). Example 3: Location of new bus stops There is obvious need for organizing and scheduling of public transport. A main goal of the application is to create / change / delete bus stops and bus stations and to connect the different stops and stations so that they reach a maximum number of people (in city centres, near points of interest …) in the shortest possible time. Another purpose is to provide up-to-date information about the routes and stops to all the employees and citizens. Several scenarios are envisaged for the location of a new bus stop; the area served by the bus stop is delimited (e.g. less than 300 m or less than 5 or 10 minutes walking). Then, the application computes the population that may beneficiate of this new bus stop (see common use case B1.2 about computation of population at day and at night). Example 4 : Location of new highway (or high speed train) Location of new highway is a complex process in which several steps are required. The purpose is double:

- serve transport needs as much as possible - disturb local population as few as possible

The first step is to define the rough areas where the highway should be located.

Rough area(s) where the highway should be located

Number of buildings and inhabitants 1 km around the highway

Figure n° 119: studies to find better location of a new highway

Then, there is then a need to assess the impact of the project (to identify which buildings are concerned by the project). Visibility / intervisibility maps may be created for this project, e.g. to ensure that a nice site is visible from the highway / the train or to identify the least visible areas along the transport network).



Noise maps may be simulated to show the impact of the new highway or railway.

Current status With anti-noise wall With tunnel

Figure n° 120: Simulation of anti-noise infrastructure impact

3D representation to make 3D model simulating the new project are useful to communicate with the inhabitants impacted by the project. Example 5: Location of a new wind farm An electricity company is looking for new sites to set up wind turbines. In first phase, geographic data is required to identify potential sites. Then, the study is completed by field survey. Data related to buildings are required because wind turbines must be far enough from buildings


Name Location of a new wind farm

Priority high

Description The purpose is to identify the potential location of new wind farms.

Pre-condition


Step 1. Download INSPIRE theme AC, MF, BU, EL, TN, PS, CP

Step 2 Compute the areas that receive enough wind (see common use case B1.1 modelling of physical phenomena)

Step 3 A wind farm must be at least at 500 m from a residential building. Using attribute current use, select residential buildings. Create an exclusion zone by making a buffer of 500 m around the 2D geometry of these buildings.

Step 4

Using attributes construction nature and specific interest, select the specific buildings or constructions that generate easements for wind turbines (castles, churches, radars, television towers, antennas, pylons, transformers, airports, SEVESO sites). More generally, the buildings that have an interest for landscape generate more constraints than ordinary buildings. These buildings are those having historical or architectural interest, some are under official classification / protection but not all (for instance, traditional, well-preserved village

Step 5

Make visibility maps around the specific buildings that generate more constraints; for these specific buildings, a detailed 3D geometry with location of openings enables more detailed results. The areas where the wind farm is visible from these specific buildings must be excluded.




Step 6 The area where it is possible to locate a new wind farm is now known. But it is necessary to get owner agreement. The cadastral parcels located in the favourable area are selected and the owner is found using the national cadastral reference and the negotiation may begin….

Result The location for a new wind farm is found.


Description INSPIRE themes AC, MF, BU, EL, TN, PS, CP

Geographic scope Windy areas in Europe

Example 4 : High voltage power line An electricity company need to set up a new high voltage power line crossing an inhabited area.


Name Location of a new high voltage power line

Priority high

Description The purpose is to check that the new line will not be in conflict with existing buildings.

Pre-condition The potential location of the power line has been defined


Step 1. Download INSPIRE theme BU

Step 2

The power line is above ground. Using the attributes 2D geometry + height (or elevation preferably captured at highest point) or the 3D geometry of buildings and other constructions, check if the scheduled location of power line is fine, i.e. if it respects the minimum distances

Step 3

The power line is underground. Using the attributes 2D geometry (preferably captured as envelope) and height below ground or number of floors below ground, check if the scheduled location of power line is fine, i.e. if it respects the minimum distances

Result The location for the new high voltage power line has been checked.


Description INSPIRE themes BU

Geographic scope Anywhere in Europe

15.2 Management of service/activity Part 2: Narrative explanation of the use case Example 1: computing population reached by television channels The national government wants to assess the percentage of population that receive television channels.




Name Computation of population reached by television channels

Priority medium

Description The purpose is to compute population reached by television channels, using a grid for population

Pre-condition There is a software taking the population grid as input to check which population was reached or not by television channels.


Step 1. Download INSPIRE theme BU, SU, PD

Step 2 Attribute a number of inhabitants for each building (see first steps of common use case B1.2.1 Computation of population at night), using attributes 2D geometry, number of floors and current use (residential).

Step 3

Select for each building the nearest node of the grid (regular grid of 100m). The result of the query may be stored using the inspireID. If available, use 2D geometry as point to make computation quicker. If not available, the point geometry may be derived from the polygon geometry.

Step 4 Give to each node of the grid the population of the buildings related to this grid node.

Result The population data is available in the way suitable for the software.


Description INSPIRE themes BU, SU, PD


NOTE 1: This example shows the interest of multiple representations of buildings as polygons and as points. NOTE 2: In a current statistical project of Eurostat, the population has to be related to the cells of a km² grid. The methodology for doing so (transfer of statistical data from existing statistical units to a new kind of statistical units) might be quite similar. Example 2: managing refuse collection A public body has to organise the refuse collection in a city. A building in this context will either be a dwelling or premise that requires local authority service delivery in the form of waste collection services.


Name Management of refuse collection

Priority medium

Description The purpose is to manage in an efficient way the refuse collection in a city.

Pre-condition


Step 1. Download INSPIRE theme BU, US, PF, TN, AD, ..

Step 2 Using attribute condition of construction, the functional buildings (those deserving refuse collection) are selected.




Step 3 The volume of expected refuse is assessed according to the current use of the building and to its size (official area or area derived from 2D geometry x number of floors)

Step 4 Itineraries for refuse collection are prepared, based on the results of previous assessments. The 2D geometry of buildings may be used to prepare working maps (see common use case B1.3 Large scale mapping)

Step 5 When the owner / occupier of the building contact the local authority via the call centre, it is necessary to be able to find the concerned building. This may be done by using the external reference to link geographic data to the information system of owners/occupants

Step 6

Temporal studies are carried out in order to prepare evolutions of the refuse collection, e.g.

- study of the past by reconstituting the city with attributes date of construction, date of demolition

- study in next future by taking into account buildings whose condition of construction is under project or under construction

Result The refuse collection is managed in an efficient way..


Description INSPIRE themes BU, US, PF, TN, AD, ..


Example 3 : Landing of stratospheric balloons French Spatial Agency (CNES) is in charge of launching stratospheric balloons over France and other countries. These stratospheric balloons are not inhabited; they are guided either from CNES in Toulouse or from the launch site. They carry scientific material for studying atmospheric conditions (e.g. winds) or composition. There are lots of demands for example in the context of climate change and of decrease of ozone layer. These studies enable better understanding of current status of atmosphere and some anticipation. Landing of balloons may be dangerous for the people living in the landing area. There are thresholds which should not be exceeded. The risk depends on the characteristics (mainly weight) of balloon and of landing area. For instance, for the heaviest (and so the most dangerous balloons), the risk factor should not exceed 1 or 2 persons/km2. The landing area may be up to several km2. Building data are used to compute this risk factor (see common use case Computation of population at night) and to so to check if the scheduled landing area conforms to the regulation.

15.3 Management / valorisation of public patrimony Part 1: UML use case diagram



uc Infrastructure

Management / valorisation of public

patrimony

Citizens

National/local governments

Ministry of Budget

Private owners


Preservation

Public owners

Figure n° 121: use case diagram for management: valorisation of public patrimony

Part 2: Narrative explanation of the use case National and local governments as well as other public bodies are generally owners of a significant part of land and of buildings. They obviously need building data for their infrastructure projects but also for daily management. Part 3: Detailed, structured description of the use case Use Case Description

Name Managing Public Property

Priority medium

Description The purpose is to manage public property.



Step 1. Download INSPIRE theme BU, US, CP

Step 2

Decision is taken to constitute a land reserve. The owners who let their buildings abandoned may be good willing to sell their property. Based on attribute condition of construction, select the buildings and construction that are declined or ruins. Based on the national cadastral reference of parcels and/or the external reference of buildings or building units, identify the owner in the cadastral register. The official value may be used to estimate the price the local/national government will propose.

Step 3 A dispute occurs with neighbours of a public building, for instance about adjoining walls. Any document linked to the building may help to understand the issue and to solve it.

Step 4

The public body decides to assess if the buildings devoted to governmental services are well-employed. This may be done for instance by comparing the area of the building (official area or area derived from 2D geometry and number of floors) to the occupancy of the governmental service.

Public body needs to manage its public property (e.g. maintenance activities and costs, concessions of public property and tax payments). This may be done using the INSPIRE application schema for core localised data and to plug the information systems dedicated to management using the external reference to buildings and building units. This will enable the set of stakeholders to share common understanding of the spatial part of the whole information system,




Result Public property is managed in an efficient way ; results of this management may be communicated in a way understandable by the various stakeholders.




16 Census

16.1 European Census Part 1: UML use case diagram

uc European Census

European Census

Eurostat

Citizens

National statistical institutes

Local/national governments

Figure n° 122: use case diagram for European census Part 2: Narrative explanation of the use case Each 10 years, the EU Member States have to conduct a census of population and dwellings. There is a set of related documents:

− legislation (the Directive on Population and Housing Censuses) − technical regulation − programme (for instance, date for the 2011 census shall be transmitted by 2014 at the

latest). Eurostat is collecting data coming from the Member States (National Institutes of Statistics). In principle, the Member States can decide themselves on the data sources and methodology for their census. Whereas a full enumeration is the ideal for a census, some topics might be covered by means of a sample. For the dwellings, the Member States generally establish a complete frame, i.e. they base the data transmitted to Eurostat on a complete list of buildings/dwellings. Often the censuses in the Member States may use questionnaires to dwelling owner or occupant; it may also use reference data from building registry or other data bases. The data related to buildings is also useful for National Institutes to find the dwellings and the inhabitants. Part 3: Detailed, structured description of the use case


Name Census of population and dwellings

Priority high

Description The purpose is to make the census of population and dwellings, according to the European Directives on Population and Housing Censuses




Pre-condition Location of statistical units is known (INSPIRE theme SU).


Step 1. Download INSPIRE themes BU, SU and other data required for large scale mapping.

Step 2 Within the area of interest, using attribute current use, select residential buildings. These are the buildings to be investigated by census agents.

Step 3 Prepare working maps for census agents as described in B1.3. Residential buildings may/should be highlighted.

Step 4.

If available, census agents may use INSPIRE BU data for the census of dwellings:

- type of building from current use - number of floors from number of floors above ground - period of construction from date of construction - material of building from material of structure, material of

walls, material of roofs - state of repair (partly) from condition of construction - water supply, toilet facility, number of rooms, type of heating

from the mechanism of external reference to a cadastral or dwelling register where this information may be found.

Step 5 Other necessary data is collected by the census agent, during field survey, through questionnaires filled by the owner or occupant of the buildings.

Step 6. The collected data is aggregated at SU level.


Step 4 bis.

The information for census may also be collected from field survey (through the questionnaires) The INSPIRE BU data (if available) may be used for quality control. Possibly, the results of the census are used to update the INSPIRE BU data.

Result The results of the census are available for theme PD. Possible update of theme BU.


Description INSPIRE themes SU, BU


16.2 Census Units Part 1: UML use case diagram

uc Definition of census units

Census Unit Delimitation

Eurostat

National Statistical Agencies

Citizens

United Nations



Figure n° 123: use case diagram for Census Units delimitation Part 2: Narrative explanation of the use case The purpose is to redefine urban units, according to United Nations recommendations. These rules give general principle: definition of continuous areas of residential buildings. However, the rules are rather flexible and practical implementation may vary according to the country. For instance, in France, the criteria to be respected are the following:

- Urban area are composed of one or several municipalities with continuous built-up area. Each municipality must have more than half of its population in the urban area.

- The distance between 2 residential buildings must be less than 200 m - Each urban unit must have more than 2 000 inhabitants - Bridges, public land (cemeteries, stadium, airports …) and commercial or industrial buildings are

not considered as interruptions in urban areas. Other countries may have different thresholds for population and/or for maximum distance

between 2 buildings. Part 3: Detailed, structured description of the use case The step by step description is very similar to the common use case B1.4 deriving medium scale data.


Name Urban units

Priority high

Description The purpose is to define continuous urban areas, according to United Nations recommendations.

Pre-condition


Step 1. Download INSPIRE themes BU, US, TN, AU

Step 2

Define the generalisation rules to derive urban units from themes BU, US, TN, PD, … For instance, in France, the criteria to be respected are the following:

- Urban area are composed of one or several municipalities with continuous built-up area. Each municipality must have more than half of its population in the urban area.

- The distance between 2 residential buildings must be less than 200 m

- Each urban unit must have more than 2 000 inhabitants - Bridges, public land (cemeteries, stadium, airports, …) and

commercial or industrial buildings are not considered as interruptions in urban areas.

Step 3 Run the generalisation rules on large scale data.

Result The geometry of the urban units is defined and is available for theme SU


Description INSPIRE themes BU, US, TN, ..


Error! Not a valid filename.



Annex C (informative)

Template for additional information - Theme Buildings

Chosen profile Explain shortly which profile the data set has implemented among the ones proposed by INSPIRE

- core 2D profile - extended 2D profile (whole profile or part of it) - core 3D profile - extended 3D profile (whole profile or part of it)

Population of spatial objects, attributes and associations In the column “Populated”, tick (X) the populated elements. The feature type or property should be ticked if it is populated, at least for some objects. Feature types and attributes related to core profiles are shown in grey in the following table. INSPIRE element Populated INSPIRE element Populated Building BuildingPart geometry2D geometry2D geometry3D geometry3D inspireId inspireId elevation elevation conditionOfConstruction conditionOfConstruction dateOfConstruction dateOfConstruction dateOfRenovation dateOfRenovation dateOfDemolition dateOfDemolition externalReference externalReference heightAboveGround heightAboveGround name name beginLifespanVersion beginLifespanVersion endLifespanVersion endLifespanVersion currentUse currentUse numberOfBuildingUnits numberOfBuildingUnits numberOfFloorsAboveGround numberOfFloorsAboveGround BuildingNature BuildingNature numberOfDwellings numberOfDwellings Aggregation with BuildingPart Aggregation with BuildingPart officialArea officialArea officialValue officialValue heightBelowGround heightBelowGround numberOfFloorsBelowGround numberOfFloorsBelowGround floorDistribution floorDistribution floorDescription floorDescription materialOfStructure materialOfStructure materialOfRoof materialOfRoof materialOfFacade materialOfFacade roofType roofType energyPerformance energyPerformance heatingSource heatingSource heatingSystem heatingSystem



connectionToElectricity connectionToElectricity connectionToGas connectionToGas connectionToSewage connectionToSewage connectionToWater connectionToWater association with cadastral parcels association with cadastral parcels association with address association with address OtherConstruction Installation geometry2D geometry2D geometry3D geometry3D inspireId inspireId elevation elevation conditionOfConstruction conditionOfConstruction dateOfConstruction dateOfConstruction dateOfRenovation dateOfRenovation dateOfDemolition dateOfDemolition heightAboveGround heightAboveGround externalReference externalReference name name beginLifespanVersion beginLifespanVersion endLifespanVersion endLifespanVersion otherConstructionNature installationNature BuildingUnit externalReference inspireID geometry2D geometry3D beginLifespanVersion endLifespanVersion currentUse officialArea officialValue energyPerformance heatingSource heatingSystem connectionToElectricity connectionToGas connectionToSewage connectionToWater association with cadastral parcels association with address ClosureSurface GroundSurface geometry3D geometry3D inspireId inspireId beginLifespanVersion beginLifespanVersion endLifespanVersion endLifespanVersion OuterFloorSurface OuterCeilingSurface geometry3D geometry3D inspireId inspireId beginLifespanVersion beginLifespanVersion endLifespanVersion endLifespanVersion RoofSurface WallSurface geometry3D geometry3D inspireId inspireId beginLifespanVersion beginLifespanVersion endLifespanVersion endLifespanVersion materialOfRoof materialOfWall Door Window



geometry3D geometry3D inspireId inspireId beginLifespanVersion beginLifespanVersion endLifespanVersion endLifespanVersion Room InteriorInstallation geometry3D geometry3D inspireId inspireId beginLifespanVersion beginLifespanVersion endLifespanVersion endLifespanVersion roomNature internalInstallationNature ParameterizedTexture imageURI mimeType textureType Selection criteria: Building (and BuildingPart, if any) Explain which buildings are captured for INSPIRE and which are not. For instance, is there a minimum size for data capture? Are there some categories of buildings that are not captured? If the definition is significantly different from the one used by INSPIRE, provide it. OtherConstruction (if any) Explain which OtherConstructions are captured and which are not. BuildingUnit (if any) Explain what is considered as a BuildinUnit Installation (if any) Explain which Installations are captured and which are not. Data capture process – data capture rules For 2D profiles, explain if data is captured as 2D or as 2,5D data. For 3D data, explain briefly which levels of details are used; if textures are provided, give explanations about them (for which buildings, which kind of textures, …). Provide the main rules to capture buildings and constructions, with focus on the aspects that are not already included in UML model Examples:

- What is considered as a building? What is considered as part of building (if any)? - in case of a generalised capture of building, which are the main generalisation rules? - how are specific buildings (without roof) captured? - are buildings cut by cadastral boundaries? - may two buildings overlap? In which cases?

Temporal aspects

Old data Explain if the building data set published for INSPIRE contains only current version or also depreciated features. If it is the case, explain which (e.g. from when?) If necessary, give more detailed explanations about temporal attributes (e.g. how demolished buildings are considered)



Life-cycle rules: Give the life-cycle rules of buildings and constructions (i.e. in which cases an object will get a new inspire identifier and in which case an object will just be considered as a new version of same object) Mapping with INSPIRE values Attribute currentUse The classification of buildings in source data is likely different from the one proposed by INSPIRE. Explain the mappings that are not obvious, that are only approximations (e.g. what occurs in case of mix use?) Other attributes Any mapping that is not obvious correspondence should be documented. Generic mechanisms ExternalReference Explain which information systems may be connected to buildings (and building units) and what kind of information may be found. For instance: - cadastral register: information about owner(s), evaluation of building - dwelling register: information about type of dwelling (number of rooms) and comfort elements (toilets, type of heating …) - database of buildings receiving public : type of building, capacity, … Document Explain which kinds of document are generally available. For instance: - sketch of each floor for all buildings - construction permits for buildings after 1980 - photos of façade for noticeable buildings Extensible code lists Some code lists in theme BU are extensible. In case a producer adds some possible values to one or several of these code lists, these values must be documented (by definition and possibly description)

Any other useful information Add in this paragraph any other information you consider helpful for users (and not already included in the INSPIRE specification or in previous paragraphs of this template or in other metadata elements).



Annex F (informative)

<Acknowledgements>

16.3 As-is analysis Person Organisation Product Country

WG on CadastreINSPIREd

EuroGeographics – Permanent Committee on Cadastre

Cadastre data Europe

Julius Ernst Federal office of Surveying and Metrology (BEV).

Digital Cadastral Map (DKM)

Austria

Frederic Mortier General Administration of Patrimonial Documentation

CadMap - CaBu Belgium

Frederic Mortier NGI (Nationaal Geografisch Insituut) IGN (Institut Géographique National)

ITGI VRef Belgium


ITGI VGen Belgium


TOP250v-GIS Belgium

Geoffroy Detry Comité Technique de Cartographie de la Région wallonne (SPW)

PICC Belgium

Frederic Mortier GIS-Flanders (AGIV) GRB Belgium Frederic Mortier Brussels Region

Informatics Center (BRIC)

UrbIS Adm, UrbIS Top and UrbIS Map

Belgium

Karen Skeljo FOT (municipalities) and KMS

FOT + BDR Denmark

Hanno Kuus Estonian Land Board Estonian National Topographic Database

Estonia

Mare Braun Ministry of Economic Affairs and Communications

Register of Construction Works

Estonia

Laurent Breton Institut Géographique National

BD UNI , BD TOPO France

Grégoire Maillet Institut Géographique National

Bâti 3D France

Gerhard Gröger Working Committee of the Surveying Authorities of the States of the Federal Republic of Germany (AdV) –

AAA project (ALKIS-AFIS-ATKIS), unified model for cadastre (ALKIS) and topography (ATKIS)

Germany



Zsuzsanna Ferencz

Institute of Geodesy, Cartography and Remote Sensing

Land Administration-cadastral map

Hungary

Bronislovas Mikuta State Enterprise Centre of Registers (SECR)

Real property cadastre DB Real property cadastral map

Lithuania

Frank Kooij Kadaster (Netherlands' Cadastre, Land Registry, and Mapping Agency)

National Registers of Addresses and Buildings (BAG)

Netherlands

Lars Mardal Morten Borrebaek

Geovekst (Norwegian Mapping Authorithy in cooperation with other public authorithies)

FKB-Bygning (Base Data Building

Norway

Ewa Wysocka GUGiK (Head Office of Geodesy and Cartography)

EGiB (Land and Building Cadastre) – cadastral data TOPO/TBD (Topographical database) – topographical data

Poland

Adriana Padureanu Romania-National Agency for Cadastre and Land Registration(NACLR)

E-terra (cadastre and land book) INTRAVILAN (census)

Romania

Adriana Padureanu Minister of Regional Development and Tourism

SISDIEBU (estate domain and urban data base)

Romania

Martina Behulakovia Geodesy, Cartography and Cadastre Authority of the Slovak Republic

CSKN (Centrálny systém katastra nehnuteľností) and ZB GIS (Topographic database GIS)

Slovakia

Tomas Petek Surveying and Mapping Authority of the Republic of Slovenia

Building cadastre database

Slovenia

Amalia Velasco

Spanish Directorate General for Cadastre, - Ministry of Economy and Finance

Spanish Cadastre Spain

Eddie Bergström National Land Survey Grunddata Byggnad (Base Data Building)

Sweden

Marc Nicodet Swiss cadastral surveying

Federal Directorate of Cadastral Surveying

Switzerland

Simon Barlow Ordnance Survey

MasterMap Topography Layer

Great Britain

Simon Barlow Local Government Information House

National Land and Property Gazetteer

England and Wales

16.4 User requirements Person Organism Result



EEA (European Environmental Agency)

Joint meeting with TWG BU

Julián Álvarez Gallego

ADIF (Administrador de Infraestructuras Ferroviarias). Dirección de Patrimonio y Urbanismo.

Check-list about railway building management

Giorgio Arduino Regione Piemonte, DG ENV

Check-list about air quality monitoring and assessment

Olivier Banaszak Direction of Urban Studies and Prospective – Le Havre City

Check-list about urban studies –Le Havre

Dolors Barrot CENG (Specialised Commission for Geographic Standards)

Check-list about Urban Topographic database - Spain

Jose I. Barredo Floods Action, IES, JRC Check-list about implementation of Flood Directive in Europe

François Belanger INVS (Institute of Health Monitoring) - France

Check-list about Health studies - France

Laurent Breton Vector database Service - Institut Géographique National - France

Check-list about accurate land cover - France

Bert Boterbergh Agency for Roads and Traffic, Flemish Government - Belgium

Check-list about ADA Road database - Belgium

Eric Cajoly Marketing Unit - Institut Géographique National - France

Check-list about Territoire 3D - France

Aline Clozel Community of Agglomeration Avignon - France

Check-list about Habitat – Avignon- France

Marie-Christine Combes

Direction of Urbanism – Paris municipality - France

Check-list about urbanism in Paris - France

Antony Cooper Commission on Geospatial Data Standards – International Cartographic Association

Contribution to check-list crowd-sourcing for INSPIRE

Jerôme Cortinovis Air Normand - France Check-list about air quality – Normandy - France

A. Czerwinski IGG, University of Bonn, coordinator of Noise emission simulation and mapping implementation in North Rhine Westphalia

Check-list about Implementation of EU Environmental Noise Directive in North Rhine Westphalia

Matthijs Danes Alterra Wageningen UR

Check-list about effects of city on temperature and air quality

Tom De Groeve Joint Research Centre of the European Commission

Check-list about risk analysis and loss estimation for wind storms

Laurent Delgado Consulting Unit - Institut Géographique National - France

Check-lists : - Urban Units (for Statistical

Institute) - Efficiency of antenna (for

telecommunication company) - Population grid for television

coverage (for (National Council of Audiovisual).

Jean-Luc Déniel SHOM (Hydrographic and Oceanograpic Service of Navy)

Check-list about safety of marine navigation

Alexandra Delgado Jiménez

Observatory on Sustainability in Spain (OSE)/Studies of location of new services

Check-list about architecture and urban planning - Spain

Yannick Depret Marketing Unit - Institut Géographique National - France

List of possible use cases - France

Ekkehard Petri Statistical Office of the European Communities - DG Eurostat -Unit D.2 - Geographical Information LUXEMBOURG

Check-list about GISCO data base



M Foote Willis Research Network Check list about insurance Jean-Marie Fournillier

Grand Lyon - France Check-list about Grand Lyon

Julien Gaffuri Joint Research Centre (JRC) - European Commission Contact point for TWG BU

Check-list about research projects - urban analysis - simulation of urban

development Check-list about Waste Water Treatment Directive

Jean-François Girres COGIT (Research Laboratory) – Institut Géographique National - France

Check-list about OpenStreetMap

Bruno Gourgand CERTU (Centre for Studies on Transport, Network, Urbanism and Public Constructions) - France

List of possible use cases + contact points - France

Silvio Granzin

Federal environment agency Austria, department for Contaminated Sites, Vienna

Check-list about Register of potentially contaminated sites, Austria

Cédric Grenet Community of municipalities Seine Valley – Caux region - France

Check-list about 3D models

G. Gröger Project leader of project to implement tool for estimation of solar potential of roof surfaces, at IGG, University of Bonn

Check-list about Sun Exposure Calculation for Roof Surfaces

Anders Grönlund Lantmäteriet - Sweden Check-list about flood forecasting Mark Halliwell UK Hydrographic Office Check-list about marine charts Javier Hervás

Land Management and Natural Hazards Unit Institute for Environment and Sustainability Joint Research Centre (JRC) - European Commission

Check-list about landslide risk

Jan Hjelmager Commission on Geospatial Data Standards – International Cartographic Association

Contribution to check-list crowd-sourcing for INSPIRE

Hanne Moller Jensen

Region Zealand - Denmark Check list about earth pollution.

Hooft Elise Flemish Heritage Institute (Vlaams Instituut voor het Onroerend Erfgoed)

Check-list about inventory of architectural Heritage in the Flemish Region

Kenneth Ibsen Agency for Spatial and Environmental Planning - Denmark

Check-list about modelling and monitoring wastewater discharge - Denmark

INSPIRE TWG Production and Industrial Facilities

INSPIRE TWG Production and Industrial Facilities

Check-list about industrial risk

Yolène Jahard Consulting Unit – Institut Géographique National - France

Check-list about valorisation of patrimony for railway company.

Frédérique Janvier SOeS - Ministry of Sustainable Development - France

Check-list about environmental statistics

Laurent Jardinier CERTU (Centre for Studies on Transport, Network, Urbanism and Public Constructions) - France

Check-list about sustainable transport - France

Steffen Kuntz

geoland2 project Check-list about Urban Atlas

Gregor Kyi Eurostat – Census unit

Check-list about census of population and dwellings



Jean-Christopher Lambert

Belgian Institute for Space Aeronomy (IASB-BIRA)

Check-list about atmospheric Research - Belgium

Gerard Leenders Land Registry and Mapping Agency, Netherlands

Check-list about EULIS

Luc Lefebvre CNES (French Spatial Agence)

Check-list about stratospheric balloons - France

Marc Léobet MIG (Mission of Geographic Information) - France

Check-list about Risk management - France

Matthew Longman Ashfield District Council - UK

Check-list about Local Authority Refuse Collection - UK

Josefa Lopez Barragán

INE (National Statistics Institute) Check-list about Population and Housing Census - Spain

David Ludlow Centre for Research in Sustainable Planning and Environments – UK (?)

Check-list about Urban sprawl – EEA initiative

José Ramón Martinez Cordero

Subdirección General de Dominio Público Marítimo-Terrestre. Secretaría General del Mar. Ministerio de Medio Ambiente y Medio Rural y Marino.

Check-list about protection of coastal areas - Spain

Johan Mortier Elia High voltage power line management - Belgium

Susana Munoz Gas Natural Fenosa - Spain Check-list about database for gas and electricity management - Spain

Anne Nærvig-Petersen

Statistics Denmark Check-list about Housing inventory- Denmark

Ana-Maria Olteanu France Telecom Check-list about implementation of new antennas for mobile phone.

Nicolas Paparoditis MATIS (Research Laboratory on Images) - Institut Géographique National - France

Check-list about façade thermography

Simon Parkinson Smart Industry Design Team - Iberdrola-ScottishPower

Check-list about energy retail – supply

Véronique Pereira Consulting Unit - Institut Géographique National - France

Check-lists : - obstacles for air transport (for

SIA -Service of Aeronautical Information)

- easements for air transport (for STBA Technical Service of Aerial Bases)

- Noise maps (for CSTB Centre Technical Security of Buildings)

- Sun exposure (for electricity companies)

Manuela Pfeiffer State agency for agriculture, environment and rural areas of the state Schleswig-Holstein - Germany

Check-list about implementation of Flood Directive in Germany

Odile Rascol INSEE (National Statistical Institute) - France

Check-list about buildings for census

Marianne Ronsbro Region Zealand - Denmark Check list about earth pollution. Jean-Pierre Sabatier CUB Bordeaux (Community of

Agglomeration) – France Check-list about roof thermography - France

François Salgé Ministry of Sustainable Development - France Facilitator TWG LU

Check-list about GéoPLU (France) and plan4all (Europe)

Marc Salvador General Directorate of Department Check-lists:



Segarra of the Interior, institutional relations and participation, Generalitat de Catalunya - Spain

-security and emergency – Spain - prevention, extinction of fires and bailouts and rescues

David Sánchez Blázquez

Programa de Impulso al Urbanismo en Red - Spain

Check-list about “urbanismo en red”

Per Sandqvist Lantmäteriet - Sweden Check-list about blue lights services Jesus San Miguel JRC FOREST Action (European

Forest Fire Information System – EFFIS) :

Check-list about forest fire risk

Tristan Saramon IBERDROLA RENOVABLES FRANCE.

Check-list about new wind farms

Claudia Secco Regione Piemonte Department of Environment

Check-list about noise map calculation

Markus Seifert Facilitator of INSPIRE TWG PS Check-list about protection of historic buildings

J. Steinrücken IGG, Univ. of Bonn, project leader of several bicycle and tourism route planning tools/portals - Germany

Check-list about tourism/leisure - Germany

Yvan Strubbe Flemish public transport company (VVM De Lijn)

Check-list about scheduling of public transport. (new bus stops) - Belgium

Karl-Erik Svensson National Board of Housing, Building and Planning

Check-list about Energy Performance of Building Directive (EPDB)

Fabio Taucer Joint Research Centre, ELSA Unit, IPSC, European Commission

Check-list about Seismic risk analysis and loss estimation.

Guilllaume Touya COGIT (Research Laboratory) – Institut Géographique National - France

Check-list about OpenStreetMap

Gaspar Valls Solé Office of Urbanism and economic activities. Diputació de Barcelona (Barcelona Provincial Council)- Spain

Check-lists: - location of economic activities – Spain - SITMUN project: Municipal Territorial Information System Barcelona

Miet Van Den Eeckhaut

Land Management and Natural Hazards Unit- Institute for Environment and Sustainability Joint Research Centre (JRC) - European Commission

Check-list about landslide risk

Frans van der Storm Program manager X-border-GDI (Netherlands – Germany)

Check-list about X-Border GDI applications (risk atlas, spatial planning)

Ana Velasco CartoCiudad project- (National Geographic Institute of Spain-National Center of Geographic Information CNIG).

Check-list about CartoCiudad project - Spain

Maarten Vermeyen Flemish Heritage Institute (Vlaams Instituut voor het Onroerend Erfgoed)

Check-list about inventory of architectural Heritage in the Flemish Region

François Virevialle Mapping Unit – Institut Géographique National - France

Check-list about historic and archaeological GIS in Bordeaux

Magnus Walestad Statistics Sweden Check-list about building permits as indication for economic forecasts

Scott Wilson EUROCONTROL Check-list about Air Traffic Management