Directive 2007/2/EC of the European Parliament and of the Council of 14 March 2007 establishing an Infrastructure for Spatial Information in the European Community (INSPIRE)
+
+
+
+
+
Foreword
+
How to read the document?
+
+
This document describes the "INSPIRE data specification on Agricultural and Aquaculture Facilities – Technical Guidelines" version 3.1.0 as developed by the Thematic Working Group (TWG) TWG AF using both natural and a conceptual schema language.
+
+
+
The data specification is based on a common template[1] used for all data specifications, which has been harmonised using the experience from the development of the Annex I, II and III data specifications.
+
+
+
This document provides guidelines for the implementation of the provisions laid down in the Implementing Rule for spatial data sets and services of the INSPIRE Directive. It also includes additional requirements and recommendations that, although not included in the Implementing Rule, are relevant to guarantee or to increase data interoperability.
+
+
+
Two executive summaries provide a quick overview of the INSPIRE data specification process in general, and the content of the data specification on Agricultural and Aquaculture Facilities in particular. We highly recommend that managers, decision makers, and all those new to the INSPIRE process and/or information modelling should read these executive summaries first.
+
+
+
The UML diagrams (in Chapter 5) offer a rapid way to see the main elements of the specifications and their relationships. The definition of the spatial object types, attributes, and relationships are included in the Feature Catalogue (also in Chapter 5). People having thematic expertise but not familiar with UML can fully understand the content of the data model focusing on the Feature Catalogue. Users might also find the Feature Catalogue especially useful to check if it contains the data necessary for the applications that they run. The technical details are expected to be of prime interest to those organisations that are responsible for implementing INSPIRE within the field of Agricultural and Aquaculture Facilities, but also to other stakeholders and users of the spatial data infrastructure.
+
+
+
The technical provisions and the underlying concepts are often illustrated by examples. Smaller examples are within the text of the specification, while longer explanatory examples and descriptions of selected use cases are attached in the annexes.
+
+
+
In order to distinguish the INSPIRE spatial data themes from the spatial object types, the INSPIRE spatial data themes are written in italics.
+
+
+
+
+
+
+
+
The document will be publicly available as a 'non-paper'. It does not represent an official position of the European Commission, and as such cannot be invoked in the context of legal procedures.
+
+
+
+
+
Legal Notice
+
+
+
Neither the European Commission nor any person acting on behalf of the Commission is responsible for the use which might be made of this publication.
+
+
+
Interoperability of Spatial Data Sets and Services – General Executive Summary
+
+
The challenges regarding the lack of availability, quality, organisation, accessibility, and sharing of spatial information are common to a large number of policies and activities and are experienced across the various levels of public authority in Europe. In order to solve these problems it is necessary to take measures of coordination between the users and providers of spatial information. The Directive 2007/2/EC of the European Parliament and of the Council adopted on 14 March 2007 aims at establishing an Infrastructure for Spatial Information in the European Community (INSPIRE) for environmental policies, or policies and activities that have an impact on the environment.
+
+
+
INSPIRE is based on the infrastructures for spatial information that are created and maintained by the Member States. To support the establishment of a European infrastructure, Implementing Rules addressing the following components of the infrastructure have been specified: metadata, interoperability of spatial data sets (as described in Annexes I, II, III of the Directive) and spatial data services, network services, data and service sharing, and monitoring and reporting procedures.
+
+
+
INSPIRE does not require collection of new data. However, after the period specified in the Directive[2] Member States have to make their data available according to the Implementing Rules.
+
+
+
Interoperability in INSPIRE means the possibility to combine spatial data and services from different sources across the European Community in a consistent way without involving specific efforts of humans or machines. It is important to note that "interoperability" is understood as providing access to spatial data sets through network services, typically via Internet. Interoperability may be achieved by either changing (harmonising) and storing existing data sets or transforming them via services for publication in the INSPIRE infrastructure. It is expected that users will spend less time and efforts on understanding and integrating data when they build their applications based on data delivered in accordance with INSPIRE.
+
+
+
In order to benefit from the endeavours of international standardisation bodies and organisations established under international law their standards and technical means have been utilised and referenced, whenever possible.
+
+
+
To facilitate the implementation of INSPIRE, it is important that all stakeholders have the opportunity to participate in specification and development. For this reason, the Commission has put in place a consensus building process involving data users, and providers together with representatives of industry, research and government. These stakeholders, organised through Spatial Data Interest Communities (SDIC) and Legally Mandated Organisations (LMO)[3], have provided reference materials, participated in the user requirement and technical[4] surveys, proposed experts for the Data Specification Drafting Team[5], the Thematic Working Groups[6] and other ad-hoc cross-thematic technical groups and participated in the public stakeholder consultations on draft versions of the data specifications. These consultations covered expert reviews as well as feasibility and fitness-for-purpose testing of the data specifications[7].
+
+
+
This open and participatory approach was successfully used during the development of the data specifications on Annex I, II and III data themes as well as during the preparation of the Implementing Rule on Interoperability of Spatial Data Sets and Services[8] for Annex I spatial data themes and of its amendment regarding the themes of Annex II and III.
+
+
+
The development framework elaborated by the Data Specification Drafting Team aims at keeping the data specifications of the different themes coherent. It summarises the methodology to be used for the development of the data specifications, providing a coherent set of requirements and recommendations to achieve interoperability. The pillars of the framework are the following technical documents[9]:
+
+
+
+
+
The Definition of Annex Themes and Scope 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 Model 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, some common code lists, etc. Those requirements of the Generic Conceptual Model that are directly implementable are included in the Implementing Rule on Interoperability of Spatial Data Sets and Services.
+
+
+
The Methodology for the Development of Data Specifications 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 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 Common data models are a set of documents that specify data models that are referenced by a number of different data specifications. These documents include generic data models for networks, coverages and activity complexes.
+
+
+
+
+
The structure of the data specifications is based on the "ISO 19131 Geographic information - Data product specifications" standard. They include the technical documentation of the application schema, the spatial object types with their properties, and other specifics of the spatial data themes using natural language as well as a formal conceptual schema language[10].
+
+
+
A consolidated model repository, feature concept dictionary, and glossary are being maintained to support the consistent specification development and potential further reuse of specification elements. The consolidated model consists of the harmonised models of the relevant standards from the ISO 19100 series, the INSPIRE Generic Conceptual Model, and the application schemas[11] developed for each spatial data theme. The multilingual INSPIRE Feature Concept Dictionary contains the definition and description of the INSPIRE themes together with the definition of the spatial object types present in the specification. The INSPIRE Glossary defines all the terms (beyond the spatial object types) necessary for understanding the INSPIRE documentation including the terminology of other components (metadata, network services, data sharing, and monitoring).
+
+
+
By listing a number of requirements and making the necessary recommendations, the data specifications enable full system interoperability across the Member States, within the scope of the application areas targeted by the Directive. The data specifications (in their version 3.0) are published as technical guidelines and provide the basis for the content of the Implementing Rule on Interoperability of Spatial Data Sets and Services[12]. The content of the Implementing Rule is extracted from the data specifications, considering short- and medium-term feasibility as well as cost-benefit considerations. The requirements included in the Implementing Rule are legally binding for the Member States according to the timeline specified in the INSPIRE Directive.
+
+
+
In addition to providing a basis for the interoperability of spatial data in INSPIRE, the data specification development framework and the thematic data specifications can be reused in other environments at local, regional, national and global level contributing to improvements in the coherence and interoperability of data in spatial data infrastructures.
+
+
+
Agricultural and Aquaculture Facilities – Executive Summary
+
+
The data specification for Agricultural and Aquaculture Facilities is required to facilitate the interoperability of geographical information related to these topics among member states. In the context of this data specification Agricultural and Aquaculture Facilities concern the description of all the physical instruments and constructions with permanent or semi permanent emplacement (inland or outland) that are related to Agricultural and Aquaculture Activities. The general scope has been extended beyond the scope of the term "facility" in order to allow the inclusion of information about delimited portions of land or water related to Agricultural and Aquaculture activities that are subjected by law to special permission, monitoring or management ("plots"). The intention is to cover the potential lacks in the scope of other Thematic working groups also covering Agricultural or Aquaculture concepts but with a different level of detail. Mainly it could be possible to define that Agricultural and Aquaculture Facilities scope covers all the terms related to the Agricultural and Aquaculture activities in which is possible to identify a legal responsible for their management or operation.
+
+
+
Although the title of the thematic group involves two different concepts, Agricultural and Aquaculture, both scopes have been included on the same conceptual model. This is because the model has been defined based on the abstractions of geographical entities required by the legislation. In that sense, in the model Agricultural Holding is defined at the same level than Aquaculture Holding being able to identify separately through the Activity performed (attribute). The same rule applies to other levels of detail like installations.
+
+
+
This data specification does not include information related to areas of management that involve sets of holdings grouped by different criteria (areas affected by diseases) or classification of the land (urban and rural planning) which should be covered by other INSPIRE thematic areas.
+
+
+
The thematic scope of this data specification is aimed to provide a solid framework for mapping, reporting and modelling purposes. This is necessary to support policy formulation through better reporting and management of pan European initiatives, such as waste management, water, animal movements, epidemiological control, food traceability, etc where Agricultural and Aquaculture Facilities data fulfils a function in relating information to real world objects.
+
+
+
The Agricultural and Aquaculture Facilities theme concerns the physical elements related with these kinds of activities. It does not define attributes that should be reported and, as a consequence, it should not be considered in isolation from other INSPIRE themes or reporting obligations as described by other legislations. It is also acknowledged that the model might be extended with further user requirements identified in the future.
+
+
+
Considering the relevance of the Agricultural and Aquaculture activities over the territory and in consequence over the environment, the thematic working group (TWG) has decided to include the geographic description of different entities from simple installations to plots; it is expected that relevant developments such as the European WISE and SEIS projects will use this specification as a base for further extension with reporting obligations within the EU.
+
+
+
The data specification has been prepared by the thematic working group on Agricultural and Aquaculture Facilities, a multinational team of experts in the field drawn from all parts of the European Union. Their brief has been to create a specification, which requires no additional data capture by member states, and is in addition, easily understood and as flexible as possible. In this way it is designed to minimize the effort required to supply conformant data.
+
+
+
The data specification has been based on existing standards, as far as possible.
+
+
+
Acknowledgements
+
+
Many individuals and organisations have contributed to the development of these Guidelines.
+
+
+
The Thematic Working Group Agriculture and Aquaculture Facilities (AF) included:
+
+
+
János Busznyák (TWG Facilitator from Sep.2011 to Sep.2012), Frans van Diepen (TWG Editor), Norma Rauthe, Carolina Escobedo, Vincenzo Angileri, Fabrizio Natale, Angel López (European Commission contact point).
+
+
+
Other contributors to the INSPIRE data specifications are the Drafting Team Data Specifications, the JRC Data Specifications Team and the INSPIRE stakeholders - Spatial Data Interested Communities (SDICs) and Legally Mandated Organisations (LMOs).
+
+
+
Contact information
+
+
+
Maria Vanda Nunes de Lima & Michael Lutz
+European Commission Joint Research Centre (JRC)
+Institute for Environment and Sustainability
+Unit H06: Digital Earth and Reference Data
+http://inspire.ec.europa.eu/index.cfm/pageid/2
This document specifies a harmonised data specification for the spatial data theme Agricultural and Aquaculture Facilities as defined in Annex III of the INSPIRE Directive.
+
+
+
This data specification provides the basis for the drafting of Implementing Rules according to Article 7 (1) of the INSPIRE Directive [Directive 2007/2/EC]. The entire data specification is published as implementation guidelines accompanying these Implementing Rules.
+
+
+
+
+
+
2. Overview
+
+
+
2.1. Name
+
+
INSPIRE data specification for the theme Agricultural and Aquaculture Facilities.
+
+
+
+
2.2. Informal description
+
+
Definition:
+
+
+
(INSPIRE, 2007) Farming equipment and production facilities (including irrigation systems, greenhouses and stables). [Directive 2007/2/EC]
+
+
+
Description:
+
+
+
The scope of "Agricultural and Aquaculture Facilities" thematic working group refers to all the physical instruments and constructions with permanent or semi-permanent emplacement (inland or outland) that are related to Agricultural and Aquaculture Activities (under the NACE Classification – level A - "Agriculture, forestry and fishing"). Including:
+
+
+
+
+
A - Agriculture, forestry and fishing
+
+
+
+
A1 - Crop and animal production, hunting and related service activities
+
+
+
+
A1.1 - Growing of non-perennial crops
+
+
+
A1.2 - Growing of perennial crops
+
+
+
A1.3 - Plant propagation
+
+
+
A1.4 - Animal production
+
+
+
A1.5 - Mixed farming
+
+
+
A1.6 - Support activities to agriculture and post-harvest crop activities
+
+
+
+
+
+
+
+
+
…
+
+
+
A3 - Fishing and aquaculture
+
+
+
+
…
+
+
+
A3.2 - Aquaculture
+
+
+
+
A3.2.1 - Marine aquaculture
+
+
+
A3.2.2 - Freshwater aquaculture
+
+
+
+
+
+
+
+
+
+
+
Activities listed below such as catching, hunting, fishing or collection of natural resources (vegetables or animal) on their natural environment could be included under the scope when supported by relevant physical instruments and constructions but always constraining the information to them as required on Data Specifications. Entities referring extended areas should be considered under most appropriate themes as (AM, SU or CP). These could be:
+
+
+
+
+
A3.1 - Fishing
+
+
+
+
A3.1.1 - Marine fishing
+
+
+
A3.1.2 - Freshwater fishing
+
+
+
+
+
+
…
+
+
+
A1.7 - Hunting, trapping and related service activities
+
+
+
+
A1.7.0 - Hunting, trapping and related service activities
+
+
+
+
A2 - Forestry and logging
+
+
+
+
+
+
+
+
+
A2.1 - Silviculture and other forestry activities
+
+
+
+
A2.1.0 - Silviculture and other forestry activities
+
+
+
+
+
+
A2.2 - Logging
+
+
+
+
A2.2.0 - Logging
+
+
+
+
+
+
A2.3 - Gathering of wild growing non-wood products
+
+
+
+
A2.3.0 - Gathering of wild growing non-wood products
+
+
+
+
+
+
A2.4 - Support services to forestry
+
+
+
+
A2.4.0 - Support services to forestry
+
+
+
+
+
+
+
+
Under the Agricultural and Aquaculture scope, "Facility" is considered as a generic term that refers to physical structures or sets of them designed, built or installed to serve a specific function (agricultural or aquaculture) and areas of land or water where such structures are or may be located. Based on this generic definition, the scope covers a wide range of entities from Holdings to Abstract Installations (Specific Technical Units).
+
+
+
"Facilities" dedicated to the optimal conservation of materials directly derived from Agricultural or Aquaculture Activities and placed into the "Site" limits of the "Holding" in which these materials have been produced are covered by the scope (e.g. Milk raw tanks). "Facilities" related to Activities of marketing and transformation of raw materials into elaborated products in an industrial way would be under the scope of other themes (PF, US, BU), similar case occurs for those activities carried out on the Holding - Site but not directly related to Agricultural or Aquaculture activities as they have been described and without a relevant impact on the environment (e.g. hosting of persons or recreational activities), .
+
+
+
All the "facilities" where animals are bred or kept for uses not directly related to Agriculture or Aquaculture activities would be under the scope if existing datasets related to agricultural or aquaculture include them because of their purposes (e.g. for the purpose of "epidemiological control of animal diseases" equestrian centers may be included).
+
+
+
All physical instruments and constructions that are part of the rural landscape but not legally related to specific agricultural or aquaculture holdings (related party - operator) could be included under the scope but always constraining the information to them as required on Data Specifications..
+
+
+
All the geographical entities delimiting areas in which holdings are grouped by different criteria shall be under the scope of other themes (AM, HH, SU) (e.g relaying areas, infected zones or compartment, irrigation areas,…).
+
+
+
The extended part of the model includes delimited portions of land or water ("plots") in which agricultural (including animal farming) and/or aquaculture labours are carried out. The scope was extended to this class beyond the scope of the term "facility" in order to cover "Data Set" dealing with information about actions over delimited extensions of territory (inland or on water) related to Agricultural and Aquaculture activities and under the direct supervision or responsibility of a "Holding" that are subjected by law to special permission, monitoring or management. The intention is to cover the potential lack of other scopes like Land Use or Land Cover in which the figure of the "Related Party - Operator" is not considered.
+
+
+
Scope, use examples:
+
+
+
Agricultural and Aquaculture Holdings (Activity Complex Extension as described in Doc 2.10 "INSPIRE Base Models") as human activities taking place over the territory, are directly related to the environment in which they are located (land, water and air); in that context, they are subject to diverse legislation (from Local to European).
+
+
+
As Economical Activities, they are subjected to a wide range of common legislation derived from their operations (waste, e-prtr, seveso, water,…). Use case and examples based on this could be for instance the definition of Waste Management Plans or the delimitation of areas of special care or susceptibility related to different risk sources (e.g Nuclear radioactivity or chemical emissions).
+
+
+
As source of food for consumption, all these holdings are also subjected to a wide range of sanitary legislation and animal care and management (traceability, animal health, cattle registry,…). (e.g. control of animal diseases, cattle registration of movements, …)
+
+
+
As activities taking place directly over the environment, extracting and consuming resources from it (land, water) they are also subjected to legislation that control the use of resources and the use of certain kind of substances (Nitrates, Irrigation, Manure, …).
+
+
+
Important feature types and attributes:
+
+
+
Agricultural and Aquaculture facilities, Holdings, independently of their use, may have an exact and fixed location (point, line, area).
+
+
+
Holding location may exist as coordinates or indirectly through the address, property (cadastral information) or buildings. Use of GIS or web services may join their databases and databases offering possibilities for indirect referencing.
+
+
+
Objects (things or constructions) can be spatially expressed as points or polygons depending on the scale. Lineal facilities can be expressed as networks (arc-node).
+
+
+
Plots must be described as polygons (surfaces).
+
+
+
+
+
+
+
+
Definition:
+
+(INSPIRE, 2007) Farming equipment and production facilities (including irrigation systems, greenhouses and stables). [Directive 2007/2/EC]
+
+Description:
+
+The theme "Agricultural and Aquaculture Facilities" concerns the description of all the physical instruments and constructions with permanent or semi-permanent emplacement (inland or outland) that are related to agricultural and aquaculture activities.
+
+Agriculture refers to the set of process and activities consisting in cultivating soils, producing crops and rearing animals; it includes harvesting, milking, breeding animals, keeping animals for farming purposes, and, according to Council Regulation 73/2009, maintaining the land in good agricultural and environmental condition. Agricultural facilities include facilities ranging from entire holdings to installations such as irrigation systems, drainage systems, greenhouses, stables, barns, silos and tanks.
+
+Aquaculture covers activities and techniques related to the production, breeding and treatment of fish, molluscs, seaweed and other kinds of aquatic resources (vegetables or animal). Aquaculture facilities only include permanent or semi-permanent systems or constructions for breeding, treatment and raising of organisms. Aquaculture facilities may exist both in marine waters, inland water environments and as terrestrial production systems.
+
+Catching, hunting or collection of natural resources (vegetables or animal) on their natural environment is not considered as an agricultural activity, unless it is supported by relevant physical instruments and constructions. Similarly, forestry is not considered as an agricultural activity, with the exception of tree nurseries.
+
+Entry in the INSPIRE registry: http://inspire.ec.europa.eu/theme/af/
+
+
+
+
+
+
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 19125-1] EN ISO 19125-1:2004, Geographic Information – Simple feature access – Part 1: Common architecture
+
+
+
[ISO 19135] EN ISO 19135:2007 Geographic information – Procedures for item registration (ISO 19135:2005)
+
+
+
[ISO 19138] ISO/TS 19138:2006, Geographic Information – Data quality measures
+
+
+
[ISO 19139] ISO/TS 19139:2007, Geographic information – Metadata – XML schema implementation
+
+
+
[ISO 19157] ISO/DIS 19157, Geographic information – Data quality
+
+
+
[OGC 06-103r4] Implementation Specification for Geographic Information - Simple feature access – Part 1: Common Architecture v1.2.1
+
+
+
NOTE This is an updated version of "EN ISO 19125-1:2004, Geographic information – Simple feature access – Part 1: Common architecture".
+
+
+
[Regulation 1205/2008/EC] Regulation 1205/2008/EC implementing Directive 2007/2/EC of the European Parliament and of the Council as regards metadata
+
+
+
[Regulation 976/2009/EC] Commission Regulation (EC) No 976/2009 of 19 October 2009 implementing Directive 2007/2/EC of the European Parliament and of the Council as regards the Network Services
+
+
+
[Regulation 1089/2010/EC] Commission Regulation (EU) No 1089/2010 of 23 November 2010 implementing Directive 2007/2/EC of the European Parliament and of the Council as regards interoperability of spatial data sets and services
+
+
+
[Regulation 1893/2006] Regulation (EC) no 1893/2006 of the European Parliament and of the Council of 20 December 2006 establishing the statistical classification of economic activities NACE Revision 2 and amending Council Regulation (EEC) No 3037/90 as well as certain EC Regulations on specific statistical domains.
+
+
+
+
2.4. Terms and definitions
+
+
General terms and definitions helpful for understanding the INSPIRE data specification documents are defined in the INSPIRE Glossary[13].
+
+
+
Specifically, for the theme Agricultural and Aquaculture Facilities, the following terms are defined:
+
+
+
(1) Activity Complex
+
+
+
It refers to a single unit, both technically and economically, which has a single management and which undertakes classified economic activities
+
+
+
In Agriculture and Aquaculture the Holding class is an extension of Activity Complex.
+
+
+
(2) Agriculture
+
+
+
It refers to the set of process and activities consisting in cultivating soils, producing crops and rearing animals; it includes harvesting, milking, breeding animals and keeping animals for farming purposes. According to Council Regulation 73/2009 maintaining the land in good agricultural and environmental condition shall be considered as an agricultural activity.
+
+
+
(3) Livestock
+
+
+
Refers to animals being bred and/or raised for use or profit (covered by the activities defined under NACE codes A.1.4. and A.1.5).
+
+
+
(4) Aquaculture:
+
+
+
Set of activities and techniques related to the production, breeding and treatment of fish, molluscs, seaweed and other kinds of aquatic resources (vegetables or animal).
+
+
+
Farming systems are diverse:
+
+
+
+
+
Freshwater, brackish water or saltwater environment.
+
+
+
For on-growing, hatcheries and nurseries.
+
+
+
In cages, tanks, ponds, enclosures and pens, re-circulation systems, mollusks on bottom, molluscs off bottom.
+
+
+
+
+
(5) Utility
+
+
+
Object (thing or construction), simple or complex (integrated by parts or pieces), that is useful for a specific use.
+
+
+
(6) Production
+
+
+
From the economic point of view production is to create utility, being utility the capacity to generate satisfaction through a product, an economic service or an economic good.
+
+
+
(7) Installation:
+
+
+
Set of physical elements, operating in a coordinated manner, that are requested to perform a particular activity.
+
+
+
Installations include:
+
+
+
+
+
Storage and distribution facilities (gas, liquid, solid).
+
+
+
Power facilities (Generating, distribution and transformation)
+
+
+
Industrial Machines and Equipment (Industrial and Automated Processes)
Independent portion of land or water surface (clearly delimited e.g by fences, walls or boundery markers) including (or matching) on the limits of a Site, that is the support for a specific use directly related to the Agricultural or Aquaculture activities performed by the Holding.
+
+
+
(9) Area
+
+
+
Portion of territory (Land Use - Urban Planning) in which it is possible to perform a legal implantation of Agricultural or Aquaculture Facilities. It’s also a quantity expressing the two-dimensional size of a defined part of a surface, typically a region bounded by a closed curve.
+
+
+
(10)Facility
+
+
+
A physical structure designed, built or installed to serve a specific function and areas of land or water where such structures are or may be located.
+
+
+
+
2.5. Symbols and abbreviations
+
+
+
+
+
+
+
+
ATS
+
Abstract Test Suite
+
+
+
CLP
+
Classification, labelling and packaging of substances and mixtures
+
+
+
EC
+
European Commission
+
+
+
EEA
+
European Environmental Agency
+
+
+
E-PRTR
+
European - Pollutant Release and Transfer Register
+
+
+
ETRS89
+
European Terrestrial Reference System 1989
+
+
+
ETRS89-LAEA
+
Lambert Azimuthal Equal Area
+
+
+
EVRS
+
European Vertical Reference System
+
+
+
EWC
+
European Waste Catalogue
+
+
+
FAO
+
Food and Agricultural Organization of the United Nations.
+
+
+
GCM
+
General Conceptual Model
+
+
+
GML
+
Geography Markup Language
+
+
+
IPPC
+
Integrated pollution prevention and control
+
+
+
IR
+
Implementing Rule
+
+
+
ISDSS
+
Interoperability of Spatial Data Sets and Services
+
+
+
ISO
+
International Organization for Standardization
+
+
+
ITRS
+
International Terrestrial Reference System
+
+
+
LAT
+
Lowest Astronomical Tide
+
+
+
LMO
+
Legally Mandated Organisation
+
+
+
NACE
+
Statistical Classification of Economical Activities in Europe.
+
+
+
SDIC
+
Spatial Data Interest Community
+
+
+
TG
+
Technical Guidance
+
+
+
UML
+
Unified Modeling Language
+
+
+
UTC
+
Coordinated Universal Time
+
+
+
XML
+
EXtensible Markup Language
+
+
+
+
+
+
2.6. How the Technical Guidelines map to the Implementing Rules
+
+
The schematic diagram in Figure 1 gives an overview of the relationships between the INSPIRE legal acts (the INSPIRE Directive and Implementing Rules) and the INSPIRE Technical Guidelines. The INSPIRE Directive and Implementing Rules include legally binding requirements that describe, usually on an abstract level, what Member States must implement.
+
+
+
In contrast, the Technical Guidelines define how Member States might implement the requirements included in the INSPIRE Implementing Rules. As such, they may include non-binding technical requirements that must be satisfied if a Member State data provider chooses to conform to the Technical Guidelines. Implementing these Technical Guidelines will maximise the interoperability of INSPIRE spatial data sets.
+
+
+
+
+
+
+
+
Figure 1 - Relationship between INSPIRE Implementing Rules and Technical Guidelines
+
+
+
2.6.1. Requirements
+
+
The purpose of these Technical Guidelines (Data specifications on Agricultural and Aquaculture Facilities) is to provide practical guidance for implementation that is guided by, and satisfies, the (legally binding) requirements included for the spatial data theme Agricultural and Aquaculture Facilities in the Regulation (Implementing Rules) on interoperability of spatial data sets and services. These requirements are highlighted in this document as follows:
This style is used for requirements contained in the Implementing Rules on interoperability of spatial data sets and services (Commission Regulation (EU) No 1089/2010).
+
+
+
+
+
+
+
For each of these IR requirements, these Technical Guidelines contain additional explanations and examples.
+
+
+
NOTE The Abstract Test Suite (ATS) in Annex A contains conformance tests that directly check conformance with these IR requirements.
+
+
+
Furthermore, these Technical Guidelines may propose a specific technical implementation for satisfying an IR requirement. In such cases, these Technical Guidelines may contain additional technical requirements that need to be met in order to be conformant with the corresponding IR requirement when using this proposed implementation. These technical requirements are highlighted as follows:
+
+
+
+
+
+
📒
+
+
+
+
TG Requirement X This style is used for requirements for a specific technical solution proposed in these Technical Guidelines for an IR requirement.
+
+
+
+
+
+
+
NOTE 1 Conformance of a data set with the TG requirement(s) included in the ATS implies conformance with the corresponding IR requirement(s).
+
+
+
NOTE 2 In addition to the requirements included in the Implementing Rules on interoperability of spatial data sets and services, the INSPIRE Directive includes further legally binding obligations that put additional requirements on data providers. For example, Art. 10(2) requires that Member States shall, where appropriate, decide by mutual consent on the depiction and position of geographical features whose location spans the frontier between two or more Member States. General guidance for how to meet these obligations is provided in the INSPIRE framework documents.
+
+
+
+
2.6.2. Recommendations
+
+
In addition to IR and TG requirements, these Technical Guidelines may also include a number of recommendations for facilitating implementation or for further and coherent development of an interoperable infrastructure.
+
+
+
+
+
+
📘
+
+
+
+
Recommendation X
+
+
+
Recommendations are shown using this style.
+
+
+
+
+
+
+
NOTE The implementation of recommendations is not mandatory. Compliance with these Technical Guidelines or the legal obligation does not depend on the fulfilment of the recommendations.
+
+
+
+
2.6.3. Conformance
+
+
Annex A includes the abstract test suite for checking conformance with the requirements included in these Technical Guidelines and the corresponding parts of the Implementing Rules (Commission Regulation (EU) No 1089/2010).
+
+
+
+
+
+
+
+
3. Specification scopes
+
+
+
This data specification does not distinguish different specification scopes, but just considers one general scope.
+
+
+
NOTE For more information on specification scopes, see [ISO 19131:2007], clause 8 and Annex D.
+
+
+
+
+
+
4. Identification information
+
+
+
These Technical Guidelines are identified by the following URI:
NOTE ISO 19131 suggests further identification information to be included in this section, e.g. the title, abstract or spatial representation type. The proposed items are already described in the document metadata, executive summary, overview description (section 2) and descriptions of the application schemas (section 5). In order to avoid redundancy, they are not repeated here.
+
+
+
+
+
+
5. Data content and structure
+
+
+
5.1. Application schemas – Overview
+
+
5.1.1. Application schema included in the IRs
+
+
Articles 3, 4 and 5 of the Implementing Rules lay down the requirements for the content and structure of the data sets related to the INSPIRE Annex themes.
+
+
+
+
+
+
📕
+
+
+
+
IR Requirement
+Article 4
+Types for the Exchange and Classification of Spatial Objects
+
+
+
+
+
For the exchange and classification of spatial objects from data sets meeting the conditions laid down in Article 4 of Directive 2007/2/EC, Member States shall use the spatial object types and associated data types and code lists that are defined in Annexes II, III and IV for the themes the data sets relate to.
+
+
+
When exchanging spatial objects, Member States shall comply with the definitions and constraints set out in the Annexes and provide values for all attributes and association roles set out for the relevant spatial object types and data types in the Annexes. For voidable attributes and association roles for which no value exists, Member States may omit the value.
+
+
+
+
+
+
+
+
+
The types to be used for the exchange and classification of spatial objects from data sets related to the spatial data theme Agricultural and Aquaculture Facilities are defined in the following application schemas (see section 5.3):
+
+
+
+
+
Agricultural and Aquaculture Facilities Model application schema.
+
+
+
+
+
The application schemas specify requirements on the properties of each spatial object including its multiplicity, domain of valid values, constraints, etc.
+
+
+
An application schema may include references (e.g. in attributes or inheritance relationships) to common types or types defined in other spatial data themes. These types can be found in a sub-section called "Imported Types" at the end of each application schema section. The common types referred to from application schemas included in the IRs are addressed in Article 3.
+
+
+
+
+
+
📕
+
+
+
+
IR Requirement
+Article 3
+Common Types
+
+
+
Types that are common to several of the themes listed in Annexes I, II and III to Directive 2007/2/EC shall conform to the definitions and constraints and include the attributes and association roles set out in Annex I.
+
+
+
+
+
+
+
NOTE Since the IRs contain the types for all INSPIRE spatial data themes in one document, Article 3 does not explicitly refer to types defined in other spatial data themes, but only to types defined in external data models.
+
+
+
Common types are described in detail in the Generic Conceptual Model [DS-D2.7], in the relevant international standards (e.g. of the ISO 19100 series) or in the documents on the common INSPIRE models [DS-D2.10.x]. For detailed descriptions of types defined in other spatial data themes, see the corresponding Data Specification TG document [DS-D2.8.x].
+
+
+
+
5.1.2. Additional recommended application schema
+
+
In addition to the application schemas listed above, the following additional application schemas have been defined for the theme Agricultural and Aquaculture Facilities (see section 5.4):
+
+
+
+
+
Agricultural and Aquaculture Facilities Extended Model application schema.
+
+
+
+
+
These additional application schemas are not included in the IRs. They typically address requirements from specific (groups of) use cases and/or may be used to provide additional information. They are included in this specification in order to improve interoperability also for these additional aspects and to illustrate the extensibility of the application schemas included in the IRs.
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 1
+
+
+
Additional and/or use case-specific information related to the theme Agricultural and Aquaculture Facilities should be made available using the spatial object types and data types specified in the following application schema(s): Agricultural and Aquaculture Facilities Extended Model.
+
+
+
These spatial object types and data types should comply with the definitions and constraints and include the attributes and association roles defined in this section.
+
+
+
The code lists used in attributes or association roles of spatial object types or data types should comply with the definitions and include the values defined in this section.
+
+
+
+
+
+
+
+
+
5.2. Basic notions
+
+
This section explains some of the basic notions used in the INSPIRE application schemas. These explanations are based on the GCM [DS-D2.5].
+
+
+
5.2.1. Notation
+
+
5.2.1.1. Unified Modeling Language (UML)
+
+
The application schemas included in this section are specified in UML, version 2.1. The spatial object types, their properties and associated types are shown in UML class diagrams.
+
+
+
NOTE For an overview of the UML notation, see Annex D in [ISO 19103].
+
+
+
The use of a common conceptual schema language (i.e. UML) allows for an automated processing of application schemas and the encoding, querying and updating of data based on the application schema – across different themes and different levels of detail.
+
+
+
The following important rules related to class inheritance and abstract classes are included in the IRs.
+
+
+
+
+
+
📕
+
+
+
+
IR Requirement
+Article 5
+Types
+
+
+
(…)
+
+
+
+
+
Types that are a sub-type of another type shall also include all this type’s attributes and association roles.
+
+
+
Abstract types shall not be instantiated.
+
+
+
+
+
+
+
+
+
The use of UML conforms to ISO 19109 8.3 and ISO/TS 19103 with the exception that UML 2.1 instead of ISO/IEC 19501 is being used. The use of UML also conforms to ISO 19136 E.2.1.1.1-E.2.1.1.4.
+
+
+
NOTE ISO/TS 19103 and ISO 19109 specify a profile of UML to be used in conjunction with the ISO 19100 series. This includes in particular a list of stereotypes and basic types to be used in application schemas. ISO 19136 specifies a more restricted UML profile that allows for a direct encoding in XML Schema for data transfer purposes.
+
+
+
To model constraints on the spatial object types and their properties, in particular to express data/data set consistency rules, OCL (Object Constraint Language) is used as described in ISO/TS 19103, whenever possible. In addition, all constraints are described in the feature catalogue in English, too.
+
+
+
NOTE Since "void" is not a concept supported by OCL, OCL constraints cannot include expressions to test whether a value is a void value. Such constraints may only be expressed in natural language.
+
+
+
+
5.2.1.2. Stereotypes
+
+
In the application schemas in this section several stereotypes are used that have been defined as part of a UML profile for use in INSPIRE [DS-D2.5]. These are explained in Table 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.
+
+
+
type
+
Class
+
A type that is not directly instantiable, but is used as an abstract collection of operation, attribute and relation signatures. This stereotype should usually not be used in INSPIRE application schemas as these are on a different conceptual level than classifiers with this stereotype.
+
+
+
dataType
+
Class
+
A structured data type without identity.
+
+
+
union
+
Class
+
A structured data type without identity where exactly one of the properties of the type is present in any instance.
+
+
+
codeList
+
Class
+
A code list.
+
+
+
import
+
Dependency
+
The model elements of the supplier package are imported.
+
+
+
voidable
+
Attribute, association role
+
A voidable attribute or association role (see section 5.2.2).
+
+
+
lifeCycleInfo
+
Attribute, association role
+
If in an application schema a property is considered to be part of the life-cycle information of a spatial object type, the property shall receive this stereotype.
+
+
+
version
+
Association role
+
If in an application schema an association role ends at a spatial object type, this stereotype denotes that the value of the property is meant to be a specific version of the spatial object, not the spatial object in general.
+
+
+
+
+
+
+
5.2.2. Voidable characteristics
+
+
The «voidable» stereotype is used to characterise those properties of a spatial object that may not be present in some spatial data sets, even though they may be present or applicable in the real world. This does not mean that it is optional to provide a value for those properties.
+
+
+
For all properties defined for a spatial object, a value has to be provided – either the corresponding value (if available in the data set maintained by the data provider) or the value of void. A void value shall imply that no corresponding value is contained in the source spatial data set maintained by the data provider or no corresponding value can be derived from existing values at reasonable costs.
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 2
+
+
+
The reason for a void value should be provided where possible using a listed value from the VoidReasonValue code list to indicate the reason for the missing value.
+
+
+
+
+
+
+
The VoidReasonValue type is a code list, which includes the following pre-defined values:
+
+
+
+
+
Unpopulated: The property is not part of the dataset maintained by the data provider. However, the characteristic may exist in the real world. For example when the "elevation of the water body above the sea level" has not been included in a dataset containing lake spatial objects, then the reason for a void value of this property would be 'Unpopulated'. The property receives this value for all spatial objects in the spatial data set.
+
+
+
Unknown: The correct value for the specific spatial object is not known to, and not computable by the data provider. However, a correct value may exist. For example when the "elevation of the water body above the sea level" of a certain lake has not been measured, then the reason for a void value of this property would be 'Unknown'. This value is applied only to those spatial objects where the property in question is not known.
+
+
+
Withheld: The characteristic may exist, but is confidential and not divulged by the data provider.
+
+
+
+
+
NOTE It is possible that additional reasons will be identified in the future, in particular to support reasons / special values in coverage ranges.
+
+
+
The «voidable» stereotype does not give any information on whether or not a characteristic exists in the real world. This is expressed using the multiplicity:
+
+
+
+
+
If a characteristic may or may not exist in the real world, its minimum cardinality shall be defined as 0. For example, if an Address may or may not have a house number, the multiplicity of the corresponding property shall be 0..1.
+
+
+
If at least one value for a certain characteristic exists in the real world, the minimum cardinality shall be defined as 1. For example, if an Administrative Unit always has at least one name, the multiplicity of the corresponding property shall be 1..*.
+
+
+
+
+
In both cases, the «voidable» stereotype can be applied. In cases where the minimum multiplicity is 0, the absence of a value indicates that it is known that no value exists, whereas a value of void indicates that it is not known whether a value exists or not.
+
+
+
EXAMPLE If an address does not have a house number, the corresponding Address object should not have any value for the «voidable» attribute house number. If the house number is simply not known or not populated in the data set, the Address object should receive a value of void (with the corresponding void reason) for the house number attribute.
+
+
+
+
5.2.3. Code lists
+
+
Code lists are modelled as classes in the application schemas. Their values, however, are managed outside of the application schema.
+
+
+
5.2.3.1. Code list types
+
+
The IRs distinguish the following types of code lists.
+
+
+
+
+
+
📕
+
+
+
+
IR Requirement
+Article 6
+Code Lists for Spatial Data Sets
+
+
+
+
+
The code lists included in this Regulation set out the multilingual thesauri to be used for the key attributes, in accordance with Article 8(2), point (c), of Directive 2007/2/EC.
+
+
+
The Commission shall establish and operate an INSPIRE code list register at Union level for managing and making publicly available the values that are included in the code lists referred to in paragraph 1.
+
+
+
The Commission shall be assisted by the INSPIRE Commission expert group in the maintenance and update of the code list values.
+
+
+
Code lists shall be one of the following types:
+
+
+
+
code lists whose values comprise only the values specified in the INSPIRE code list register;
+
+
+
code lists whose values comprise the values specified in the INSPIRE code list register and narrower values defined by data providers;
+
+
+
code lists whose values comprise the values specified in the INSPIRE code list register and additional values at any level defined by data providers;
+
+
+
code lists, whose values comprise any values defined by data providers.
+
+
+
+
+
+
Code lists may be hierarchical. Values of hierarchical code lists may have a more general parent value.
+
+
+
Where, for an attribute whose type is a code list as referred to in paragraph 4, points (b), (c) or (d), a data provider provides a value that is not specified in the INSPIRE code list register, that value and its definition and label shall be made available in another register.
+
+
+
+
+
+
+
+
+
The type of code list is represented in the UML model through the tagged value extensibility, which can take the following values:
+
+
+
+
+
none, representing code lists whose allowed values comprise only the values specified in the IRs (type a);
+
+
+
narrower, representing code lists whose allowed values comprise the values specified in the IRs and narrower values defined by data providers (type b);
+
+
+
open, representing code lists whose allowed values comprise the values specified in the IRs and additional values at any level defined by data providers (type c); and
+
+
+
any, representing code lists, for which the IRs do not specify any allowed values, i.e. whose allowed values comprise any values defined by data providers (type d).
+
+
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 3
+
+
+
Additional values defined by data providers should not replace or redefine any value already specified in the IRs.
+
+
+
+
+
+
+
NOTE This data specification may specify recommended values for some of the code lists of type (b), (c) and (d) (see section 5.2.4.3). These recommended values are specified in a dedicated Annex.
+
+
+
In addition, code lists can be hierarchical, as explained in Article 6(2) of the IRs.
+
+
+
+
+
+
📕
+
+
+
+
IR Requirement
+Article 6
+Code Lists for Spatial Data Sets
+
+
+
(…)
+
+
+
+
+
Code lists may be hierarchical. Values of hierarchical code lists may have a more general parent value
+
+
+
+
+
+
+
+
+
The type of code list and whether it is hierarchical or not is also indicated in the feature catalogues.
+
+
+
+
5.2.3.2. Obligations on data providers
+
+
+
+
+
📕
+
+
+
+
IR Requirement
+Article 6
+Code Lists for Spatial Data Sets
+
+
+
(….)
+
+
+
+
+
Where, for an attribute whose type is a code list as referred to in paragraph 4, points (b), (c) or (d), a data provider provides a value that is not specified in the INSPIRE code list register, that value and its definition and label shall be made available in another register.
+
+
+
+
+
+
+
+
+
Article 6(6) obliges data providers to use only values that are allowed according to the specification of the code list. The "allowed values according to the specification of the code list" are the values explicitly defined in the IRs plus (in the case of code lists of type (b), (c) and (d)) additional values defined by data providers.
+
+
+
For attributes whose type is a code list of type (b), (c) or (d) data providers may use additional values that are not defined in the IRs. Article 6(6) requires that such additional values and their definition be made available in a register. This enables users of the data to look up the meaning of the additional values used in a data set, and also facilitates the re-use of additional values by other data providers (potentially across Member States).
+
+
+
NOTE Guidelines for setting up registers for additional values and how to register additional values in these registers is still an open discussion point between Member States and the Commission.
+
+
+
+
5.2.3.3. Recommended code list values
+
+
For code lists of type (b), (c) and (d), this data specification may propose additional values as a recommendation (in a dedicated Annex). These values will be included in the INSPIRE code list register. This will facilitate and encourage the usage of the recommended values by data providers since the obligation to make additional values defined by data providers available in a register (see section 5.2.4.2) is already met.
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 4
+
+
+
Where these Technical Guidelines recommend values for a code list in addition to those specified in the IRs, these values should be used.
+
+
+
+
+
+
+
NOTE For some code lists of type (d), no values may be specified in these Technical Guidelines. In these cases, any additional value defined by data providers may be used.
+
+
+
+
5.2.3.4. Governance
+
+
The following two types of code lists are distinguished in INSPIRE:
+
+
+
+
+
Code lists that are governed by INSPIRE (INSPIRE-governed code lists). These code lists will be managed centrally in the INSPIRE code list register. Change requests to these code lists (e.g. to add, deprecate or supersede values) are processed and decided upon using the INSPIRE code list register’s maintenance workflows.
+
+
INSPIRE-governed code lists will be made available in the INSPIRE code list register at http://inspire.ec.europa.eu/codelist/<CodeListName>. They will be available in SKOS/RDF, XML and HTML. The maintenance will follow the procedures defined in ISO 19135. This means that the only allowed changes to a code list are the addition, deprecation or supersession of values, i.e. no value will ever be deleted, but only receive different statuses (valid, deprecated, superseded). Identifiers for values of INSPIRE-governed code lists are constructed using the pattern http://inspire.ec.europa.eu/codelist/<CodeListName>/<value>.
+
+
+
+
Code lists that are governed by an organisation outside of INSPIRE (externally governed code lists). These code lists are managed by an organisation outside of INSPIRE, e.g. the World Meteorological Organization (WMO) or the World Health Organization (WHO). Change requests to these code lists follow the maintenance workflows defined by the maintaining organisations. Note that in some cases, no such workflows may be formally defined.
+
+
Since the updates of externally governed code lists is outside the control of INSPIRE, the IRs and these Technical Guidelines reference a specific version for such code lists.
+
+
+
The tables describing externally governed code lists in this section contain the following columns:
+
+
+
+
+
The Governance column describes the external organisation that is responsible for maintaining the code list.
+
+
+
The Source column specifies a citation for the authoritative source for the values of the code list. For code lists, whose values are mandated in the IRs, this citation should include the version of the code list used in INSPIRE. The version can be specified using a version number or the publication date. For code list values recommended in these Technical Guidelines, the citation may refer to the "latest available version".
+
+
+
In some cases, for INSPIRE only a subset of an externally governed code list is relevant. The subset is specified using the Subset column.
+
+
+
The Availability column specifies from where (e.g. URL) the values of the externally governed code list are available, and in which formats. Formats can include machine-readable (e.g. SKOS/RDF, XML) or human-readable (e.g. HTML, PDF) ones.
+
+
+
+
+
Code list values are encoded using http URIs and labels. Rules for generating these URIs and labels are specified in a separate table.
+
+
+
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 5
+
+
+
The http URIs and labels used for encoding code list values should be taken from the INSPIRE code list registry for INSPIRE-governed code lists and generated according to the relevant rules specified for externally governed code lists.
+
+
+
+
+
+
+
NOTE Where practicable, the INSPIRE code list register could also provide http URIs and labels for externally governed code lists.
+
+
+
+
5.2.3.5. Vocabulary
+
+
For each code list, a tagged value called "vocabulary" is specified to define a URI identifying the values of the code list. For INSPIRE-governed code lists and externally governed code lists that do not have a persistent identifier, the URI is constructed following the pattern http://inspire.ec.europa.eu/codelist/<UpperCamelCaseName>;.
+
+
+
If the value is missing or empty, this indicates an empty code list. If no sub-classes are defined for this empty code list, this means that any code list may be used that meets the given definition.
+
+
+
An empty code list may also be used as a super-class for a number of specific code lists whose values may be used to specify the attribute value. If the sub-classes specified in the model represent all valid extensions to the empty code list, the subtyping relationship is qualified with the standard UML constraint "\{complete,disjoint}".
+
+
+
+
+
5.2.4. Identifier management
+
+
+
+
+
📕
+
+
+
+
IR Requirement
+Article 9
+Identifier Management
+
+
+
+
+
The data type Identifier defined in Section 2.1 of Annex I shall be used as a type for the external object identifier of a spatial object.
+
+
+
The external object identifier for the unique identification of spatial objects shall not be changed during the life-cycle of a spatial object.
+
+
+
+
+
+
+
+
+
NOTE 1 An external object identifier is a unique object identifier which is published by the responsible body, which may be used by external applications to reference the spatial object. [DS-D2.5]
+
+
+
NOTE 2 Article 9(1) is implemented in each application schema by including the attribute inspireId of type Identifier.
+
+
+
NOTE 3 Article 9(2) is ensured if the namespace and localId attributes of the Identifier remains the same for different versions of a spatial object; the version attribute can of course change.
+
+
+
+
5.2.5. Geometry representation
+
+
+
+
+
📕
+
+
+
+
IR Requirement
+Article 12
+Other Requirements & Rules
+
+
+
+
+
The value domain of spatial properties defined in this Regulation shall be restricted to the Simple Feature spatial schema as defined in Herring, John R. (ed.), OpenGIS® Implementation Standard for Geographic information – Simple feature access – Part 1: Common architecture, version 1.2.1, Open Geospatial Consortium, 2011, unless specified otherwise for a specific spatial data theme or type.
+
+
+
+
+
+
+
+
+
NOTE 1 The specification restricts the spatial schema to 0-, 1-, 2-, and 2.5-dimensional geometries where all curve interpolations are linear and surface interpolations are performed by triangles.
+
+
+
NOTE 2 The topological relations of two spatial objects based on their specific geometry and topology properties can in principle be investigated by invoking the operations of the types defined in ISO 19107 (or the methods specified in EN ISO 19125-1).
+
+
+
+
5.2.6. Temporality representation
+
+
The application schema(s) use(s) the derived attributes "beginLifespanVersion" and "endLifespanVersion" to record the lifespan of a spatial object.
+
+
+
The attributes "beginLifespanVersion" specifies the date and time at which this version of the spatial object was inserted or changed in the spatial data set. The attribute "endLifespanVersion" specifies the date and time at which this version of the spatial object was superseded or retired in the spatial data set.
+
+
+
NOTE 1 The attributes specify the beginning of the lifespan of the version in the spatial data set itself, which is different from the temporal characteristics of the real-world phenomenon described by the spatial object. This lifespan information, if available, supports mainly two requirements: First, knowledge about the spatial data set content at a specific time; second, knowledge about changes to a data set in a specific time frame. The lifespan information should be as detailed as in the data set (i.e., if the lifespan information in the data set includes seconds, the seconds should be represented in data published in INSPIRE) and include time zone information.
+
+
+
NOTE 2 Changes to the attribute "endLifespanVersion" does not trigger a change in the attribute "beginLifespanVersion".
+
+
+
+
+
+
📕
+
+
+
+
IR Requirement
+Article 10
+Life-cycle of Spatial Objects
+
+
+
(…)
+
+
+
+
+
Where the attributes beginLifespanVersion and endLifespanVersion are used, the value of endLifespanVersion shall not be before the value of beginLifespanVersion.
+
+
+
+
+
+
+
+
+
NOTE The requirement expressed in the IR Requirement above will be included as constraints in the UML data models of all themes.
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 6
+
+
+
If life-cycle information is not maintained as part of the spatial data set, all spatial objects belonging to this data set should provide a void value with a reason of "unpopulated".
+
+
+
+
+
+
+
5.2.6.1. Validity of the real-world phenomena
+
+
The application schema(s) use(s) the attributes "validFrom" and "validTo" to record the validity of the real-world phenomenon represented by a spatial object.
+
+
+
The attributes "validFrom" specifies the date and time at which the real-world phenomenon became valid in the real world. The attribute "validTo" specifies the date and time at which the real-world phenomenon is no longer valid in the real world.
+
+
+
Specific application schemas may give examples what "being valid" means for a specific real-world phenomenon represented by a spatial object.
+
+
+
+
+
+
📕
+
+
+
+
IR Requirement
+Article 12
+Other Requirements & Rules
+
+
+
(…)
+
+
+
+
+
Where the attributes validFrom and validTo are used, the value of validTo shall not be before the value of validFrom.
+
+
+
+
+
+
+
+
+
NOTE The requirement expressed in the IR Requirement above will be included as constraints in the UML data models of all themes.
+
+
+
+
+
+
5.3. Application schema Agricultural and Aquaculture Facilities Model
+
+
5.3.1. Description
+
+
5.3.1.1. Narrative description
+
+
The Agricultural and Aquaculture Facilities model is composed by core information in relation to the geographical description of entities under the Agriculture and Aquaculture scope. It is based on the Activity Complex model (Doc 2.10.3). This Activity Complex model is extended to the basic Agricultural and Aquaculture features Holding and Site. These features contains only basic information about the location of the Holding and the Site, the type of activities performed on that locations, and just in case that animals are kept, what type of animals is kept on the Site.
+
+
+
A Holding is regarded as a specialisation of an Activity Complex. Each Activity Complex - Holding contains at least one or more Sites. On a Site animals can be kept. On a Site, none, one or more animal species can be recorded.
+
+
+
The location of Holding and Site can be expressed as a point or a surface (polygon).
+
+
+
The activity of Holding and Site is expressed by using the standard NACE classification list.
+
+
+
The data type FarmAnimalSpecies is expressed by using a standard code list for livestock animal species and a standard FAO code list for aquaculture species.
+
+
+
+
+
Activity Complex: The whole area and all infrastructures on it, under the control of an operator. In the AF theme the Activity Complex has the specialised representation named Holding.
+
+
+
Holding: The whole area and all infrastructures included on it, under the control of an operator to perform agricultural or aquaculture activities. It may be composed of one or more "Sites".
+
+
This concept is related to all the common information that applies over all the different entities related to the Agricultural and Aquaculture activity or activities under the responsibility of one legal operator. It could be considered as the synthetic geographical representation of a unique operational, economical or legal body.
+
+
+
+
Site: Belonging to a holding, it is the geographical representation of land that constitutes a management unit. It includes all infrastructure, equipment and materials.
+
+
The concept of "Site" is related to polygonal areas. Its definition and scope derived from the legal definition of "Site" where the term is described as:
+
+
+
All land at a distinct geographic location under the management control of an operator [Directive 2006/21/EC];
+
+
+
All land at a distinct geographic location under the management control of an organisation covering activities, products and services. This includes all infrastructure, equipment and materials [REGULATION (EC) 761/2001];
+
+
+
All "Holding" must be related at least to one "Site" but a Holding can manage one or more "Sites".
+
+
+
The geographical extension of the "Site" has been described as GM_Object to allow its representation as a point (inherited from holding) or more complex representations as a Set of Isolated Polygons (Multisurface). Topologically all the rest of geographical elements should be included under the limits of one "Site". If necessary a "Site" should be created to include each of these representative sub-elements.
+
+
+
+
Farm Animal Species: It is a Data Type related with "Site" which allows to describe the presence of animals on it.
+
+
+
+
+
+
5.3.1.2. UML Overview
+
+
+
+
+
+
+
Figure 2 – UML class diagram: Overview of the feature types and data types of the Agricultural and Aquaculture Facilities Model application schema
+
+
+
+
+
+
+
+
Figure 3 – UML class diagram: Overview of the code lists of the Agricultural and Aquaculture Facilities Model application schema
+
+
+
+
5.3.1.3. Consistency between spatial data sets
+
+
The geographical representation of Agricultural and Aquaculture Facilities (Holdings specially) must be considered as independent. That means entities described should have their own geographical definition. Although in the majority of cases a direct relation could be established with other geographical elements, this relation could become a source of errors in the accuracy of the geo-position of the elements included on the Datasets. Addresses or Cadastral Parcels information must be managed carefully to avoid overlaps and inconsistencies with information stored in existing Datasets.
+
+
+
Internally, information related to the same "facilities" or elements included on them can exist isolated in different datasets from different institutions or data providers. All this information should be unified in order to avoid duplications or redundancy of information. Other important question is the maintenance of the Topological relationship between entities mainly on those provided by different sources (data providers).
+
+
+
+
5.3.1.4. Identifier management
+
+
The Agricultural and Aquaculture Facilities data specification uses the Identifier data type from the INSPIRE General Conceptual Model [DS-D2.5]. These identifiers include version number, so they can be used to track changes to an object.
+
+
+
Agricultural and Aquaculture Facilities are subject to a multitude of identifiers depending on the applicability of the datasets in which are originally included (legal registration, registry based on legislation, …). Based on this multiplicity it is quite difficult to harmonize a criterion in order to avoid duplicity. For this reason, and based on the applicability of layers to specific use cases the model has included identifiers only at the level of the Activity Complex - Holding.
+
+
+
At the Sites level unique identifiers are not implemented.
+
+
+
+
5.3.1.5. Modelling of object references
+
+
If data providers choose to implement external object references to spatial object types in other themes, they should ensure that update mechanisms are in place in order to ensure consistency among the referenced objects.
+
+
+
+
5.3.1.6. Geometry representation
+
+
In general, the geographical information (datasets) should be provided by different organizations (Private and Public Administration related with Agricultural and Aquaculture Facilities referring at least the geographical position of the main "Holdings" as a "points" independently of the level of detail.
+
+
+
Onto the most generic legislation (Waste, IPPC, E-PRTR) the geographical information is required on Geographical coordinates (X,Y). In certain cases the geographical position could be estimated by automatic process through the "Address" provided on the registration forms. This kind of activity can derive on wrong geospatial location as result of the source information provided (e.g. legal address instead of facility address). A clean-up process over datasets should guarantee the accuracy geo-location of entities.
+
+
+
In case of "Holdings" composed by different "Sites" not continuous geographically, it would be valid to provide the geographical information related to the main one. It would not be valid, if lacks between different "Sites" are representative, defining the position as a "centroid" of all of them as geo-representation.
+
+
+
If the GM_Object element is applied as GM_Multisurface, it involves that all different "Sites" share all the attributes. This has to be considered when Farm Animal Species are described.
+
+
+
In some cases related with agricultural or aquaculture activities which cover a representative extension of land (maritime or terrestrial), "Sites", this could be provided as most detailed geographical representation of the "Holding", described as polygons (2D) in Local – Regional Datasets. Based on this option, the model include and extension for this particular case. In some cases "Sites" or Polygons in which other kind of elements included on the model are placed could be linked with cadastral parcels but this relation seems to be quite complex from the ontological point of view and it has not been considered.
+
+
+
Other kind of potential geo-referenced information is required under the legislation embedded on documents and descriptions requested without references to specific formats. This option only could be resolved with external elements (like URL’s) or the inclusion of raster layers (out of the scope).
+
+
+
The model is open to other kind of detailed elements included on the "Holding" (e.g. Installations, Plots, Technical Units). These elements should be represented by geographical entities topologically related with the "Site". In same cases the geographical representation could be coincident and inherited from the higher hierarchical level to which they belong.
+
+
+
+
+
5.3.2. Feature catalogue
+
+
Feature catalogue metadata
+
+
+
+
+
+
+
+
+
Application Schema
+
INSPIRE Application Schema Agricultural and Aquaculture Facilities Model
+
+
+
Version number
+
3.0
+
+
+
+
+
Types defined in the feature catalogue
+
+
+
+
+
+
+
+
+
+
Type
+
Package
+
Stereotypes
+
+
+
+
+
AquacultureSpeciesValue
+
Agricultural and Aquaculture Facilities Model
+
«codeList»
+
+
+
FarmAnimalSpecies
+
Agricultural and Aquaculture Facilities Model
+
«dataType»
+
+
+
Holding
+
Agricultural and Aquaculture Facilities Model
+
«featureType»
+
+
+
LivestockSpeciesValue
+
Agricultural and Aquaculture Facilities Model
+
«codeList»
+
+
+
Site
+
Agricultural and Aquaculture Facilities Model
+
«featureType»
+
+
+
+
+
5.3.2.1. Spatial object types
+
+
5.3.2.1.1. Holding
+
+
+
+
+
+
+
Holding
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
Holding
+
+
+
Subtype of:
+
ActivityComplex
+
+
+
Definition:
+
The whole area and all infrastructures included on it, covering the same or different "sites", under the control of an operator to perform agricultural or aquaculture activities. The holding includes one specialisation of ActivityComplex, ie. Activity. the values of ActivityType are expressed conform the classification of the economic activity of the holding, according to the NACE rev. 2.0 coding. Holding is a thematic extension of the generic Class "Activity Complex" shared with other thematic areas describing entities related with Economical Activities (Legal Entity Class – Business).
+
+
+
Description:
+
Accessible at Eurostat repository from URL
+http://ec.europa.eu/eurostat/ramon/nomenclatures/index.cfm?
+TargetUrl=LST_CLS_DLD&StrNom=NACE_REV2
+&StrLanguageCode=EN&StrLayoutCode=HIERARCHIC.
+
+The valid nace codes are
+first level
+01 and 03
+second level
+01.1 - 01.6 and 03.2
+third level
+01.11 - 01.64 and 03.21 - 03.22
+
+
+01.7 hunting trapping an related services is exclude.
+02. forestry and logging are excluded
+03.1 fishing is excluded.
+
+
+
Stereotypes:
+
«featureType»
+
+
+
+
+
+
+
Association role: contains
+
+
+
+
+
+
+
+
+
Value type:
+
Site
+
+
+
Multiplicity:
+
1..*
+
+
+
+
+
+
+
Constraint: ActivityValueNACE
+
+
+
+
+
+
+
+
+
Natural language:
+
+
+
+
OCL:
+
At least one of the function attributes of the Holding spatial object shall be provided using the EconomicActivityNACEValue code list (for the activity attribute of the Function data type).
+
+
+
+
+
+
+
+
+
5.3.2.1.2. Site
+
+
+
+
+
+
+
Site
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
Site
+
+
+
Definition:
+
All land at a same or distinct geographic location under the management control of a holding covering activities, products and services. This includes all infrastructure, equipment and materials. The geometry of the site must be a point or a surface. Mulitpoint or multisurface is not allowed.
+
+
+
Description:
+
The site can be represented by a point or by a surface.
+the site can have only one geometry.
+
+
+
Stereotypes:
+
«featureType»
+
+
+
+
+
+
+
Attribute: geometry
+
+
+
+
+
+
+
+
+
Name:
+
geometry
+
+
+
Value type:
+
GM_Object
+
+
+
Definition:
+
The geometry defining the extent or position of the site.
+
+
+
Description:
+
The geometry must be a GM_surface, when it includes installations, plots or buildings with a polygon type geometry.
+In case the site only includes single object with a point type geometry, the site can have a GM_point geometry.
+
+
+
Multiplicity:
+
1
+
+
+
+
+
+
+
Attribute: activity
+
+
+
+
+
+
+
+
+
Name:
+
activity
+
+
+
Value type:
+
EconomicActivityNACEValue
+
+
+
Definition:
+
The classification of the economic activity of the site, according to the NACE rev. 2.0 coding.
+
+
+
Description:
+
Accessible at Eurostat repository from URL
+http://ec.europa.eu/eurostat/ramon/nomenclatures/index.cfm?
+TargetUrl=LST_CLS_DLD&StrNom=NACE_REV2
+&StrLanguageCode=EN&StrLayoutCode=HIERARCHIC.
+
+
+The valid nace codes are
+first level
+01 and 03
+second level
+01.1 - 01.6 and 03.2
+third level
+01.11 - 01.64 and 03.21 - 03.22
+
+
+
Multiplicity:
+
1..*
+
+
+
+
+
+
+
Attribute: includesAnimal
+
+
+
+
+
+
+
+
+
Value type:
+
FarmAnimalSpecies
+
+
+
Multiplicity:
+
0..*
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
+
+
+
5.3.2.2. Data types
+
+
5.3.2.2.1. FarmAnimalSpecies
+
+
+
+
+
+
+
FarmAnimalSpecies
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
farm animal
+
+
+
Definition:
+
Identifies an animal or group of animals of the same species kept on the specific site.
+
+
+
Stereotypes:
+
«dataType»
+
+
+
+
+
+
+
Attribute: livestock
+
+
+
+
+
+
+
+
+
Name:
+
livestock
+
+
+
Value type:
+
LivestockSpeciesValue
+
+
+
Definition:
+
Define the presence of livestock species in the site.
+
+
+
Description:
+
The terrestic species are coded specified according to regulation (EC) No 1165/2008.
+
+
+
Multiplicity:
+
0..*
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: aquaculture
+
+
+
+
+
+
+
+
+
Name:
+
aquaculture
+
+
+
Value type:
+
AquacultureSpeciesValue
+
+
+
Definition:
+
Define the presence of aquaculture species in the site.
+
+
+
Description:
+
Aquaculture species are listed in aquacultureSpecies attribute.
+The allowed values for this code list comprise only the values specified in the February 2012 version of the ASFIS (Aquatic Sciences and Fisheries Information System) List of Species for Fishery Statistics Purposes maintained by FAO.
The allowed values for this code list comprise the values specified in "Annex II to Regulation (EC) No 1165/2008" and additional values at any level defined by data providers.
The allowed values for this code list comprise only the values specified in "ASFIS (Aquatic Sciences and Fisheries Information System) List of Species for Fishery Statistics Purposes published by the Food and Agriculture Organization of the United Nations" .
+
+
+
+
+
+
+
+
+
+
5.3.2.4. Imported types (informative)
+
+
This section lists definitions for feature types, data types and code lists that are defined in other application schemas. The section is purely informative and should help the reader understand the feature catalogue presented in the previous sections. For the normative documentation of these types, see the given references.
+
+
+
5.3.2.4.1. ActivityComplex
+
+
+
+
+
+
+
ActivityComplex
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
Activity Complex
+
+
+
Reference:
+
INSPIRE Data Specifications – Base Models – Activity Complex, version 1.0 [DS-D2.10.3]
+
+
+
Definition:
+
A "single unit", both technically and economically, under the management control of the same legal entity (operator), covering activities as those listed in the Eurostat NACE classification, products and services. Activity Complex includes all infrastructure, equipment and materials. It must represent the whole area, at the same or different geographical location, managed by a "single unit".
+
+
+
Description:
+
NOTE 1 This class describes the minimal set of elements necessary to describe and identify geographically a legal entity and the activities taken place on it under the context of a Environmental purposes.
+
+NOTE 2 "Activity Complex" could be assimilated to terms described on the legislation as Facility, Establishment, Plant, Holding, Organization ,Farm, Extractive Industries or Aquaculture Production Business among others
+
+EXAMPLE i.e. an Agro-business that is legally registered under the Emissions Directive.
+
+
+
+
+
+
+
+
+
5.3.2.4.2. EconomicActivityNACEValue
+
+
+
+
+
+
+
EconomicActivityNACEValue
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
Activity Complex
+
+
+
Reference:
+
INSPIRE Data Specifications – Base Models – Activity Complex, version 1.0 [DS-D2.10.3]
+
+
+
Definition:
+
Classification of economic activities according to Eurostat NACE.
+
+
+
+
+
+
+
+
+
5.3.2.4.3. GM_Object
+
+
+
+
+
+
+
GM_Object (abstract)
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
Geometry root
+
+
+
Reference:
+
Geographic information — Spatial schema [ISO 19107:2003]
+
+
+
+
+
+
+
+
+
+
+
5.3.3. Externally governed code lists
+
+
The externally governed code lists included in this application schema are specified in the tables in this section.
+
+
+
5.3.3.1. Governance and authoritative source
+
+
+
+
+
+
+
+
+
Code list
+
Governance
+
Authoritative Source (incl. version [14] and relevant subset, where applicable)
5.4. Application schema Agricultural and Aquaculture Facilities Extended Model
+
+
5.4.1. Description
+
+
5.4.1.1. Narrative description
+
+
The Extended Model represents complementary information about Agricultural and Aquaculture Facilities. It is based on extensions about plots, agri-buildings, installations, irrigation and drainage, farm animals and animal health.
+
+
+
In the extended model complementary information describes entities and process directly related to the core part entities. Elements of this part of the model can exist independently and geographically (and in the real world) but always included on the Site. There are two different extensions:
+
+
+
+
+
Detailed components: Related to physical elements that have to be independently described because of their particular function or position (quantitative information).
+
+
+
Operations: Alphanumerical information related to variables derived from operational process performed on the Site as part of one activity.
+
+
+
+
+
A Holding is regarded as a specialisation of an Activity Complex. Each Activity Complex - Holding contains at least 1 or more Sites. On a Site animals can be kept. On a Site, none, one or more animal species can be recorded.
+
+
+
A Site can contain one or more Plots. Plots are geographical features with detailed information about the activities performed on them, irrigation and drainage.
+
+
+
A Site can contain one or more AgriBuildings. These AgriBuildings can be related to Buildings (a feature defined in the Annex III theme Buildings).
+
+
+
A site can also contain one or more Installations, constructions not being buildings. These Installations can be related to Other Constructions (a feature defined in the Annex III theme Buildings).
+
+
+
In case the Installation is a waterinstallation, a water inlet or outlet device, the installation can be connected to the Appurtenance (annex III, US.core water network) or to a HydroObject (Annex I hydrography).
+
+
+
The FarmAnimalSpecies data type contains detailed information about the kind of animals kept on the site, the amount and the health status of that type of animals. The type of FarmAnimalSpecies is expressed by using a standard code list for livestock animal species. For aquaculture a standard FAO code list is used.
+
+
+
The location of Holding and Site can be expressed as a point or a surface (polygon).
+
+
+
The activity of Holding and Site is expressed by using the standard NACE codes.
+
+
+
Dedicated specialized association at the level of Site with Cadastral Parcels is implemented.
+
+
+
+
+
Holding: The whole area and all infrastructures included on it, under the control of an operator to perform Agricultural or Aquaculture activities. It may be composed of one or more "Sites".
+
+
This concept is related to all the common information that applies over all the different entities related to the Agricultural and Aquaculture activity or activities under the responsibility of one legal operator. It could be consider as the synthetic geographical representation of a unique operational, economical or legal body.
+
+
+
Activity Complex, considered as legal activities that take place over a permanent or semi-permanent portion of the territory, can be linked in several ways with other type of geographical information related on the Annex.I "reference themes".
+
+
+
Holding in the extended model include detailed information of the Holding based on the common data types described on Activity Complex general model. This allows to define a set of elements related to the activity as Inputs (understood as consumed material) and Outputs (understood as materials resulting of the activity, including pollutants, waste, final goods, waste water, …) and legal issues as permissions, and responsible parties and the role these parties have.
+
+
+
+
Site: Belonging to a holding, it is the geographical representation of land that constitutes a management unit. It includes all infrastructure, equipment and materials.
+
+
The concept of "Site" is related to polygonal areas. Its definition and scope derived from the legal definition of "Site" where the term is described as:
+
+
+
All land at a distinct geographic location under the management control of an operator [Directive 2006/21/EC];
+
+
+
All land at a distinct geographic location under the management control of an organisation covering activities, products and services. This includes all infrastructure, equipment and materials [REGULATION (EC) 761/2001];
+
+
+
All "Holding" must be related at least to one "Site" (multiplicity [1..*]) but a Holding can manage one or more "Sites". Relations must be done as constrained among both extended classes Site-Holding.
+
+
+
The geographical extension of the "Site" has been described as GM_Object to allow its representation as a point (inherited from holding) or more complex representations as a Set of Isolated Polygons (Multisurface). Topologically all the rest of geographical elements should be included under the limits of one "Site". If necessary a "Site" should be created to include each of these representative sub-elements.
+
+
+
Extended Site includes Identifier and information about the permissions based on the common data types described on Activity Complex general model.
+
+
+
+
Installation: It refers to all technical instruments and constructions included on the "Site" that should be described independently. It allows referring to specific sub-elements included on the "Site" and legally related to the "Holding".
+
+
+
Plot: This entity allows describing in a abstract sense delimited portions of land or water (independently of their size or delimitation method) included on a "Site" dedicated to a specific function as part of a major activity and geographically identifiable. "Plot" concept shouldn’t be confused with Cadastral entities despite in some cases it could be coincident on the real world with them.
+
+
+
AgriBuilding: The relation between "Buildings" and specific uses is quite fuzzy, for this reason, only buildings dedicated to specific functions related to the Activity should be linked with the Agricultural and Aquaculture model, otherwise the consistency of datasets could be quite complicated.
+
+
+
AgriBuilding: The relation between "Buildings" and specific uses is quite fuzzy, for this reason, only buildings dedicated to specific functions related to the Activity should be linked with the Agricultural and Aquaculture model, otherwise the consistency of datasets could be quite complicated.
+
+
+
HydroObject: The relation between "HydroObject" and "Installation" illustrates the link between the hydrographic system (irrigation and drainage systems) of the Site and the natural hydro objects, like ponds, lakes, rivers and canals, which are identified by annex1 theme Hydrography.
+
+
+
+
+
+
5.4.1.2. UML Overview
+
+
+
+
+
+
+
Figure 4 – UML class diagram: Overview of the Agricultural and Aquaculture Facilities Extended Model, feature classes.
+
+
+
+
+
+
+
+
Figure 5 – UML class diagram: Overview of the Agricultural and Aquaculture Facilities Extended Model, data types
+
+
+
+
+
+
+
+
Figure 6 – UML class diagram: Overview of the Agricultural and Aquaculture Facilities Extended Model, code lists part 1
+
+
+
+
+
+
+
+
Figure 7 – UML class diagram: Overview of the Agricultural and Aquaculture Facilities Extended Model, code lists part 2
+
+
+
+
5.4.1.3. Consistency between spatial data sets
+
+
No further ones to those described on 5.3.1.3
+
+
+
+
5.4.1.4. Identifier management
+
+
No further ones to those described on 5.3.1.4
+
+
+
+
5.4.1.5. Modelling of object references
+
+
No further ones to those described on 5.3.1.5
+
+
+
+
5.4.1.6. Geometry representation
+
+
No further ones to those described on 5.3.1.6
+
+
+
+
5.4.1.7. Temporality representation
+
+
No further ones to those described on 5.3.1.7
+
+
+
+
+
5.4.2. Feature catalogue
+
+
Feature catalogue metadata
+
+
+
+
+
+
+
+
+
Application Schema
+
INSPIRE Application Schema Agricultural and Aquaculture Facilities Extended Model
+
+
+
Version number
+
3.0
+
+
+
+
+
Types defined in the feature catalogue
+
+
+
+
+
+
+
+
+
+
Type
+
Package
+
Stereotypes
+
+
+
+
+
AbstractInstallation
+
Agricultural and Aquaculture Facilities Extended Model
+
«featureType»
+
+
+
AgriBuilding
+
Agricultural and Aquaculture Facilities Extended Model
+
«featureType»
+
+
+
AquacultureActivityValue
+
Agricultural and Aquaculture Facilities Extended Model
+
«codeList»
+
+
+
AquacultureInstallation
+
Agricultural and Aquaculture Facilities Extended Model
+
«featureType»
+
+
+
AquacultureInstallationValue
+
Agricultural and Aquaculture Facilities Extended Model
+
«codeList»
+
+
+
EnvironmentValue
+
Agricultural and Aquaculture Facilities Extended Model
+
«codeList»
+
+
+
FarmAnimalSpecies
+
Agricultural and Aquaculture Facilities Extended Model
+
«dataType»
+
+
+
HealthStatusValue
+
Agricultural and Aquaculture Facilities Extended Model
+
«codeList»
+
+
+
Holding
+
Agricultural and Aquaculture Facilities Extended Model
+
«featureType»
+
+
+
Installation
+
Agricultural and Aquaculture Facilities Extended Model
+
«featureType»
+
+
+
InstallationPart
+
Agricultural and Aquaculture Facilities Extended Model
+
«featureType»
+
+
+
InstallationPartValue
+
Agricultural and Aquaculture Facilities Extended Model
+
«codeList»
+
+
+
IrrigationMethodeValue
+
Agricultural and Aquaculture Facilities Extended Model
+
«codeList»
+
+
+
Plot
+
Agricultural and Aquaculture Facilities Extended Model
+
«featureType»
+
+
+
PlotActivityValue
+
Agricultural and Aquaculture Facilities Extended Model
+
«codeList»
+
+
+
RecognisedHealthStatus
+
Agricultural and Aquaculture Facilities Extended Model
+
«dataType»
+
+
+
Site
+
Agricultural and Aquaculture Facilities Extended Model
+
«featureType»
+
+
+
TypeOfAgriBuildingValue
+
Agricultural and Aquaculture Facilities Extended Model
+
«codeList»
+
+
+
WaterManagementInstallation
+
Agricultural and Aquaculture Facilities Extended Model
+
«featureType»
+
+
+
WaterSourceValue
+
Agricultural and Aquaculture Facilities Extended Model
+
«codeList»
+
+
+
+
+
5.4.2.1. Spatial object types
+
+
5.4.2.1.1. AgriBuilding
+
+
+
+
+
+
+
AgriBuilding
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
AgriBuilding
+
+
+
Definition:
+
A building used for agricultural or aquaculture activities.
+
+
+
Description:
+
A construction to store agricultural and aquaculture commodities, harvested crops , keeping of animals or storing equipment.
+
+
+
Stereotypes:
+
«featureType»
+
+
+
+
+
+
+
Attribute: identifier
+
+
+
+
+
+
+
+
+
Name:
+
identifier
+
+
+
Value type:
+
Identifier
+
+
+
Definition:
+
The identifier of the agribuilding.
+
+
+
Multiplicity:
+
1
+
+
+
+
+
+
+
Attribute: geometry
+
+
+
+
+
+
+
+
+
Name:
+
geometry
+
+
+
Value type:
+
GM_Object
+
+
+
Definition:
+
Representation of the geographical dimension/position of the "building". Can be GM_Polygon or GM_Point.
+
+
+
Multiplicity:
+
1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: typeOfBuilding
+
+
+
+
+
+
+
+
+
Name:
+
typeOfBuilding
+
+
+
Value type:
+
TypeOfAgriBuildingValue
+
+
+
Definition:
+
The type of the building, expressed as a code.
+
+
+
Description:
+
A building can consists out of one or more building parts. each building part can be of an other type.
+
+
+
Multiplicity:
+
0..*
+
+
+
+
+
+
+
Association role:
+
+
+
+
+
+
+
+
+
Value type:
+
AbstractBuilding
+
+
+
Multiplicity:
+
1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
+
+
5.4.2.1.2. AquacultureInstallation
+
+
+
+
+
+
+
AquacultureInstallation
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
AquacultureInstallation
+
+
+
Subtype of:
+
AbstractInstallation
+
+
+
Definition:
+
A technical unit or a delimited area operated by the same owner of the (aquaculture) holding, where one or more activities listed in Annex I of Regulation (EC) No 1893/2006 are carried out.
+
+
+
Description:
+
Source ( Plan4all - modified)
+
+
+
Stereotypes:
+
«featureType»
+
+
+
+
+
+
+
Attribute: aquacultureActivity
+
+
+
+
+
+
+
+
+
Name:
+
aquacultureActivity
+
+
+
Value type:
+
AquacultureActivityValue
+
+
+
Definition:
+
Type of aquaculture activity expressed as a code.
+
+
+
Description:
+
In the enumeration next values are possible:
+grown out, nursery, hatchery, other.
+
+
+
Multiplicity:
+
1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: installationType
+
+
+
+
+
+
+
+
+
Name:
+
installationType
+
+
+
Value type:
+
AquacultureInstallationValue
+
+
+
Definition:
+
Type of aquaculture installation.
+
+
+
Description:
+
In the enumeration fixed values for the types of installation are listed, like:
+ponds, tanks and raceways, enclosures and pens, etc.
+
+
+
Multiplicity:
+
1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: environment
+
+
+
+
+
+
+
+
+
Name:
+
environment
+
+
+
Value type:
+
EnvironmentValue
+
+
+
Definition:
+
The type of the environment in which the aquaculture organisms are kept. (a water classification).
+
+
+
Description:
+
The type of water can be:
+marine, freshwater or brackish water. (enumeration).
+
+
+
Multiplicity:
+
1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Association role:
+
+
+
+
+
+
+
+
+
Value type:
+
RecognisedHealthStatus
+
+
+
Multiplicity:
+
0..*
+
+
+
+
+
+
+
+
+
5.4.2.1.3. Holding
+
+
+
+
+
+
+
Holding
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
Holding
+
+
+
Subtype of:
+
ActivityComplexHolding
+
+
+
Definition:
+
The whole area and all infrastructures included on it, covering the same or different "sites", under the control of an operator to perform agricultural or aquaculture activities. The holding includes one specialisation of ActivityComplex, ie. Activity. the values of ActivityType are expressed in conformity with the classification of the economic activity of the holding, according to the NACE rev. 2.0 coding. Holding is a thematic extension of the generic Class "Activity Complex" shared with other thematic areas describing entities related with Economical Activities (Legal Entity Class – Business). Holding is a thematic extension of the generic Class "Activity Complex" shared with other thematic areas describing entities related with Economical Activities (Legal Entity Class – Business).
+
+
+
Description:
+
Accessible at Eurostat repository from URL
+http://ec.europa.eu/eurostat/ramon/nomenclatures/index.cfm?
+TargetUrl=LST_CLS_DLD&StrNom=NACE_REV2
+&StrLanguageCode=EN&StrLayoutCode=HIERARCHIC.
+
+The valid nace codes are:
+the first level codes:
+01 and 03
+the second level codes:
+01.1 - 01.6 and 03.2
+and the third level codes:
+01.11 - 01.64 and 03.21 - 03.22
+
+The next codes from the range 01 to 03.22 are excluded:
+01.7 hunting trapping an related services;
+02. forestry and logging;
+03.1 fishing.
+
+
+
Stereotypes:
+
«featureType»
+
+
+
+
+
+
+
Attribute: holdingDescription
+
+
+
+
+
+
+
+
+
Name:
+
holdingDescription
+
+
+
Value type:
+
ActivityComplexDescription
+
+
+
Definition:
+
Additional information on an Holding, including its address, a contact, related parties and a free text description.
+
+
+
Multiplicity:
+
0..1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: physicalCapacity
+
+
+
+
+
+
+
+
+
Name:
+
physicalCapacity
+
+
+
Value type:
+
Capacity
+
+
+
Definition:
+
A quantification of an actual or potential ability to perform an activity, that typically does not change, does not change often, or does not change to a significant degree.
+
+
+
Description:
+
NOTE Capacity could refer to different concepts included on the legislation as "emission limits", "capacity incineration", "nominal capacity", "objective estimation"
+
+
+
Multiplicity:
+
0..*
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: permission
+
+
+
+
+
+
+
+
+
Name:
+
permission
+
+
+
Value type:
+
Permission
+
+
+
Definition:
+
Official Decision (formal consent) granting authorization to operate all or part of a Holding , subject to certain conditions which guarantee that the installation or parts of installations on the same site operated by the same operator complies with the requirements fixed by the law or standards. A permit may cover one or more functions and fix parameters of capacity; The term may be extended to other kind of certificates or documents of special relevance depending of the scope (e.g. ISO, EMAS, National Quality Standards, etc).
+
+
+
Description:
+
NOTE This terms is referred in several legislative acts as "permit" , "authorization", "development consent" or "exploration permit" among others.
+
+EXAMPLE 1 "…a [written] decision by which the competent authority grants permission to operate all or part of an installation" ;
+EXAMPLE 2 ".. the decision of the competent authority or
+
+
+
Multiplicity:
+
0..*
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: holdingStatus
+
+
+
+
+
+
+
+
+
Name:
+
holdingStatus
+
+
+
Value type:
+
ConditionOfFacilityValue
+
+
+
Definition:
+
The status of the Holding, such as operational or decommissioned.
+
+
+
Multiplicity:
+
1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
+
+
5.4.2.1.4. AbstractInstallation
+
+
+
+
+
+
+
AbstractInstallation
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
AbstractInstallation
+
+
+
Definition:
+
Stationary technical unit part of a facility where one or more Agricultural and Aquacultural activities are carried out, and any other directly associated activities which have a technical connection with the activities carried out on that site.
+
+
+
Description:
+
Agricultural and Aquacultural Activities refers to the production of primary materials (animal and vegetal) for human use, or as base material for industrial processing (animal feed, human food or other industries).
+Depending on the scale, the installations would be represented by areas or points and always linked with a Facility (at less in a 1:1 relation).
+
+
+
Stereotypes:
+
«featureType»
+
+
+
+
+
+
+
Attribute: inspireId
+
+
+
+
+
+
+
+
+
Name:
+
inspireId
+
+
+
Value type:
+
Identifier
+
+
+
Definition:
+
The identifier of the installation.
+
+
+
Description:
+
NOTE An external object identifier is a unique object identifier published by the responsible body, which may be used by external applications to reference the spatial object. The identifier is an identifier of the spatial object, not an identifier of the real-world phenomenon.
+
+
+
Multiplicity:
+
1
+
+
+
+
+
+
+
Attribute: thematicId
+
+
+
+
+
+
+
+
+
Name:
+
thematicId
+
+
+
Value type:
+
PT_FreeText
+
+
+
Definition:
+
The identifier for the installation using a specified identification schema, such as a national register.
+
+
+
Multiplicity:
+
1
+
+
+
+
+
+
+
Attribute: geometry
+
+
+
+
+
+
+
+
+
Name:
+
geometry
+
+
+
Value type:
+
GM_Object
+
+
+
Definition:
+
The geometry defining the extent or position of the installation part.
+
+
+
Multiplicity:
+
1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: name
+
+
+
+
+
+
+
+
+
Name:
+
name
+
+
+
Value type:
+
GeographicalName
+
+
+
Definition:
+
The name of the facility.
+
+
+
Multiplicity:
+
1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: description
+
+
+
+
+
+
+
+
+
Name:
+
description
+
+
+
Value type:
+
PT_FreeText
+
+
+
Definition:
+
The description of the facility.
+
+
+
Multiplicity:
+
1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: validFrom
+
+
+
+
+
+
+
+
+
Name:
+
validFrom
+
+
+
Value type:
+
Date
+
+
+
Definition:
+
The time when the facility started to exists in the real world.
+
+
+
Multiplicity:
+
1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: validTo
+
+
+
+
+
+
+
+
+
Name:
+
validTo
+
+
+
Value type:
+
Date
+
+
+
Definition:
+
The time when the facility no longer exists in the real world.
+
+
+
Multiplicity:
+
0..1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Association role: agriRelatedHydroObject
+
+
+
+
+
+
+
+
+
Value type:
+
HydroObject
+
+
+
Multiplicity:
+
0..1
+
+
+
+
+
+
+
+
+
5.4.2.1.5. Installation
+
+
+
+
+
+
+
Installation
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
Installation
+
+
+
Subtype of:
+
AbstractInstallation
+
+
+
Definition:
+
Stationary technical unit part of a facility where one or more Agricultural and Aquacultural activities are carried out, and any other directly associated activities which have a technical connection with the activities carried out on that site.
+
+
+
Description:
+
Agricultural and Aquacultural Activities refers to the production of primary materials (animal and vegetal) for human use, or as base material for industrial processing (animal feed, human food or other industries).
+Depending on the scale, the installations would be represented by areas or points and always linked with a Facility (at less in a 1:1 relation).
+
+
+
Stereotypes:
+
«featureType»
+
+
+
+
+
+
+
+
+
5.4.2.1.6. InstallationPart
+
+
+
+
+
+
+
InstallationPart
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
InstallationPart
+
+
+
Subtype of:
+
AbstractInstallation
+
+
+
Definition:
+
Specific technical part of the Installation which is developing a representative functionality that should be registered under the legislation.
+
+
+
Description:
+
This level of description should applied for specific parts of the installations which must be register following the legislation. Manure Storage, Tanks (Special or Raw Products) ,… would be included under this definition. Independently the dimension this entity would be represented as points.
+
+
+
Stereotypes:
+
«featureType»
+
+
+
+
+
+
+
Attribute: typeCode
+
+
+
+
+
+
+
+
+
Name:
+
typeCode
+
+
+
Value type:
+
InstallationPartValue
+
+
+
Definition:
+
Describes the type of the installation part, according to a code list.
+
+
+
Multiplicity:
+
1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Association role:
+
+
+
+
+
+
+
+
+
Value type:
+
Installation
+
+
+
Multiplicity:
+
+
+
+
+
+
+
+
+
+
5.4.2.1.7. Site
+
+
+
+
+
+
+
Site
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
Site
+
+
+
Subtype of:
+
Site
+
+
+
Definition:
+
All land at a same or distinct geographic location under the management control of an organization covering activities, products and services. This includes all infrastructure, equipment and materials. The geometry of the site must be a point or a surface.
+
+
+
Description:
+
The site can be represented by a point or by a surface.
+
+
+
Stereotypes:
+
«featureType»
+
+
+
+
+
+
+
Attribute: identifier
+
+
+
+
+
+
+
+
+
Name:
+
identifier
+
+
+
Value type:
+
Identifier
+
+
+
Definition:
+
The identifier of the site.
+
+
+
Multiplicity:
+
1
+
+
+
+
+
+
+
Attribute: permission
+
+
+
+
+
+
+
+
+
Name:
+
permission — Definition – Permissions, licensed or Certifications holds by the Site to carry out "Functions" or activities under certain conditions of "Capacity" and "Time".
+
+
+
Value type:
+
Permission
+
+
+
Multiplicity:
+
0..*
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Association role:
+
+
+
+
+
+
+
+
+
Value type:
+
CadastralParcel
+
+
+
Multiplicity:
+
0..*
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Association role: includesBuilding
+
+
+
+
+
+
+
+
+
Value type:
+
AgriBuilding
+
+
+
Multiplicity:
+
0..*
+
+
+
+
+
+
+
Association role: includesPlot
+
+
+
+
+
+
+
+
+
Value type:
+
Plot
+
+
+
Multiplicity:
+
0..*
+
+
+
+
+
+
+
Association role: parent
+
+
+
+
+
+
+
+
+
Value type:
+
Site
+
+
+
Multiplicity:
+
0..*
+
+
+
+
+
+
+
Association role: hosts
+
+
+
+
+
+
+
+
+
Value type:
+
AbstractInstallation
+
+
+
Multiplicity:
+
0..*
+
+
+
+
+
+
+
Constraint: SiteExtended
+
+
+
+
+
+
+
+
+
Natural language:
+
The Site of the Holding shall be represented using the Site type of the AF Extended package.
+
+
+
OCL:
+
inv: self.parts→oclIsKindOf(AF Extended Model feature classes::Site)
+
+
+
+
+
+
+
+
+
5.4.2.1.8. Plot
+
+
+
+
+
+
+
Plot
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
Plot
+
+
+
Definition:
+
Independent portion of the land or water surface, clearly delimited, including or matching the limits of a Site, that is Holding.
+
+
+
Stereotypes:
+
«featureType»
+
+
+
+
+
+
+
Attribute: geometry
+
+
+
+
+
+
+
+
+
Name:
+
geometry
+
+
+
Value type:
+
GM_Object
+
+
+
Definition:
+
Representation of the geographical dimension/position of the plot. (polygons).
+
+
+
Multiplicity:
+
1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: area
+
+
+
+
+
+
+
+
+
Name:
+
area
+
+
+
Value type:
+
Area
+
+
+
Definition:
+
Express the size of the plot, expressed in M2.
+
+
+
Multiplicity:
+
1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: activity
+
+
+
+
+
+
+
+
+
Name:
+
activity
+
+
+
Value type:
+
EconomicActivityNACEValue
+
+
+
Definition:
+
The economic activity executed on the plot, as coded accoring to EU regulation (EC) 1200/2009, annexII, chapter 2. (codes 2.01 - 2.04.07 an 2.06.03 - 2.06.04).
The area of the plot which can be irrigated, expressed in m2.
+
+
+
Multiplicity:
+
0..1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: drainageArea
+
+
+
+
+
+
+
+
+
Name:
+
drainageArea
+
+
+
Value type:
+
Area
+
+
+
Definition:
+
The area of the plot which is equipped with artificial subsurface drainage system(s), expressed in m2.
+
+
+
Multiplicity:
+
0..1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: validFrom
+
+
+
+
+
+
+
+
+
Name:
+
validFrom
+
+
+
Value type:
+
Date
+
+
+
Definition:
+
First time at which this plot exist on this site in reality.
+
+
+
Multiplicity:
+
1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: validTo
+
+
+
+
+
+
+
+
+
Name:
+
validTo
+
+
+
Value type:
+
Date
+
+
+
Definition:
+
The time from which this plot no longer exist on this site in the real world.
+
+
+
Multiplicity:
+
0..1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Association role: parent
+
+
+
+
+
+
+
+
+
Value type:
+
Plot
+
+
+
Multiplicity:
+
0..*
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
+
+
5.4.2.1.9. WaterManagementInstallation
+
+
+
+
+
+
+
WaterManagementInstallation
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
WaterManagementInstallation
+
+
+
Subtype of:
+
AbstractInstallation
+
+
+
Definition:
+
The source of water useful for all kinds of activities of the facility site.
+
+
+
Stereotypes:
+
«featureType»
+
+
+
+
+
+
+
Attribute: waterQuantity
+
+
+
+
+
+
+
+
+
Name:
+
waterQuantity
+
+
+
Value type:
+
Measure
+
+
+
Definition:
+
The quantity of water given by the water source, in cubic metres per second.
+
+
+
Multiplicity:
+
0..1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: waterSource
+
+
+
+
+
+
+
+
+
Name:
+
waterSource
+
+
+
Value type:
+
WaterSourceValue
+
+
+
Definition:
+
Type of water source, according to Regulation (EC) No 1200/2009.
+
+
+
Multiplicity:
+
1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
+
+
+
5.4.2.2. Data types
+
+
5.4.2.2.1. FarmAnimalSpecies
+
+
+
+
+
+
+
FarmAnimalSpecies
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
farm animal
+
+
+
Subtype of:
+
FarmAnimalSpecies
+
+
+
Definition:
+
Identifies an animal or group of animals of the same specie kept on the specific site and the amount of them.
+
+
+
Stereotypes:
+
«dataType»
+
+
+
+
+
+
+
Attribute: quantity
+
+
+
+
+
+
+
+
+
Name:
+
quantity
+
+
+
Value type:
+
Number
+
+
+
Definition:
+
Numerical representation of the quantity of Animals of a certain specie (counted, estimated, weight, ..).
+
+
+
Multiplicity:
+
0..1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: measureUnit
+
+
+
+
+
+
+
+
+
Name:
+
measureUnit
+
+
+
Value type:
+
Measure
+
+
+
Definition:
+
Unit in which the quantity of animals of a certain specie is expressed.
+
+
+
Multiplicity:
+
0..1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: validFrom
+
+
+
+
+
+
+
+
+
Name:
+
validFrom
+
+
+
Value type:
+
Date
+
+
+
Definition:
+
First time at which this quantity of animals of the specified species exist on this site in the real world.
+
+
+
Multiplicity:
+
1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: validTo
+
+
+
+
+
+
+
+
+
Name:
+
validTo
+
+
+
Value type:
+
Date
+
+
+
Definition:
+
The time from at which this quantity of animals of the specified species no longer exist on this site in real world.
+
+
+
Multiplicity:
+
0..1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Association role:
+
+
+
+
+
+
+
+
+
Value type:
+
RecognisedHealthStatus
+
+
+
Multiplicity:
+
0..*
+
+
+
+
+
+
+
+
+
5.4.2.2.2. RecognisedHealthStatus
+
+
+
+
+
+
+
RecognisedHealthStatus
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
RecognisedHealthStatus
+
+
+
Definition:
+
The granted health status of the animal or animalgroup kept on the site, expressed as a staus indicator per species.
+
+
+
Stereotypes:
+
«dataType»
+
+
+
+
+
+
+
Attribute: disease
+
+
+
+
+
+
+
+
+
Name:
+
disease
+
+
+
Value type:
+
PT_FreeText
+
+
+
Definition:
+
The name of the observed disease, pest or infection of which the animal or goup of animals is suffering.
+
+
+
Multiplicity:
+
1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: recognisedHealthStatus
+
+
+
+
+
+
+
+
+
Name:
+
recognisedHealthStatus
+
+
+
Value type:
+
HealthStatusValue
+
+
+
Definition:
+
Indicator for the healthstatus, expressed per disease.
+
+
+
Multiplicity:
+
1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: validFrom
+
+
+
+
+
+
+
+
+
Name:
+
validFrom
+
+
+
Value type:
+
Date
+
+
+
Definition:
+
The date from when the healthstatus was granted.
+
+
+
Multiplicity:
+
1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: validTo
+
+
+
+
+
+
+
+
+
Name:
+
validTo
+
+
+
Value type:
+
Date
+
+
+
Definition:
+
The date from when the granted healthstatus is no longer valid.
+
+
+
Multiplicity:
+
0..1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Constraint: SiteHasFarmAnimalSpecies
+
+
+
+
+
+
+
+
+
Natural language:
+
+
+
+
OCL:
+
— Definition — RecognisedHealthStatus only applies when about at least one FarmAnimalSpecie is provided
+
+
+
+
+
+
+
+
+
+
5.4.2.3. Code lists
+
+
5.4.2.3.1. PlotActivityValue
+
+
+
+
+
+
+
PlotActivityValue
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
PlotActivityValue
+
+
+
Definition:
+
The economic activity executed on the plot, as coded accoring to EU regulation (EC) 1200/2009, annex II, chapter 2. (codes 2.01 - 2.04.07 and 2.06.03 - 2.06.04).
The allowed values for this code list comprise the values specified in Annex C and additional values at any level defined by data providers. Annex C includes recommended values that may be used by data providers.
+
+
+
+
+
+
+
+
+
5.4.2.3.2. HealthStatusValue
+
+
+
+
+
+
+
HealthStatusValue
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
HealthStatusValue
+
+
+
Definition:
+
A code list with the possible status values indicating the granted health status.
The allowed values for this code list comprise the values specified in Annex C and additional values at any level defined by data providers. Annex C includes recommended values that may be used by data providers.
The allowed values for this code list comprise the values specified in Annex C and additional values at any level defined by data providers. Annex C includes recommended values that may be used by data providers.
+
+
+
+
+
+
+
+
+
5.4.2.3.4. EnvironmentValue
+
+
+
+
+
+
+
EnvironmentValue
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
EnvironmentValue
+
+
+
Definition:
+
The type of the environment in which the aquaculture organisms are kept. (a water type classification).
The allowed values for this code list comprise the values specified in Annex C and additional values at any level defined by data providers. Annex C includes recommended values that may be used by data providers.
+
+
+
+
+
+
+
+
+
5.4.2.3.5. InstallationPartValue
+
+
+
+
+
+
+
InstallationPartValue
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
InstallationPartValue
+
+
+
Definition:
+
Describes the type of the installation part, according to a code list.
The allowed values for this code list comprise the values specified in Annex C and additional values at any level defined by data providers. Annex C includes recommended values that may be used by data providers.
The allowed values for this code list comprise the values specified in Annex C and additional values at any level defined by data providers. Annex C includes recommended values that may be used by data providers.
+
+
+
+
+
+
+
+
+
5.4.2.3.7. IrrigationMethodeValue
+
+
+
+
+
+
+
IrrigationMethodeValue
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
IrrigationMethodeValue
+
+
+
Definition:
+
List the different methods of irrigation, according to EU regulation EC 1200/2009, annex III, chapter VIII.
The allowed values for this code list comprise the values specified in Annex C and additional values at any level defined by data providers. Annex C includes recommended values that may be used by data providers.
+
+
+
+
+
+
+
+
+
5.4.2.3.8. TypeOfAgriBuildingValue
+
+
+
+
+
+
+
TypeOfAgriBuildingValue
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
TypeOfAgriBuildingValue
+
+
+
Definition:
+
The type of building, expressed as a code.
+
+
+
Description:
+
animal housing according to EU regulation (EC) 1200/2009 annex III chapter V, codes 5.01 - 5.03.99.
The allowed values for this code list comprise the values specified in Annex C and additional values at any level defined by data providers. Annex C includes recommended values that may be used by data providers.
+
+
+
+
+
+
+
+
+
5.4.2.3.9. WaterSourceValue
+
+
+
+
+
+
+
WaterSourceValue
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
WaterSourceValue
+
+
+
Definition:
+
The type of water source, according to Regulation (EC) No 1200/2009.
The allowed values for this code list comprise the values specified in Annex C and additional values at any level defined by data providers. Annex C includes recommended values that may be used by data providers.
+
+
+
+
+
+
+
+
+
+
5.4.2.4. Imported types (informative)
+
+
This section lists definitions for feature types, data types and code lists that are defined in other application schemas. The section is purely informative and should help the reader understand the feature catalogue presented in the previous sections. For the normative documentation of these types, see the given references.
+
+
+
5.4.2.4.1. AbstractBuilding
+
+
+
+
+
+
+
AbstractBuilding (abstract)
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
BuildingsBase
+
+
+
Reference:
+
INSPIRE Data specification on Buildings [DS-D2.8.III.2]
+
+
+
Definition:
+
Abstract spatial object type grouping the common semantic properties of the spatial object types Building and BuildingPart.
+
+
+
+
+
+
+
+
+
5.4.2.4.2. ActivityComplex
+
+
+
+
+
+
+
ActivityComplex
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
Activity Complex
+
+
+
Reference:
+
INSPIRE Data Specifications – Base Models – Activity Complex, version 1.0 [DS-D2.10.3]
+
+
+
Definition:
+
A "single unit", both technically and economically, under the management control of the same legal entity (operator), covering activities as those listed in the Eurostat NACE classification, products and services. Activity Complex includes all infrastructure, equipment and materials. It must represent the whole area, at the same or different geographical location, managed by a "single unit".
+
+
+
Description:
+
NOTE 1 This class describes the minimal set of elements necessary to describe and identify geographically a legal entity and the activities taken place on it under the context of a Environmental purposes.
+
+NOTE 2 "Activity Complex" could be assimilated to terms described on the legislation as Facility, Establishment, Plant, Holding, Organization ,Farm, Extractive Industries or Aquaculture Production Business among others
+
+EXAMPLE i.e. an Agro-business that is legally registered under the Emissions Directive.
+
+
+
+
+
+
+
+
+
5.4.2.4.3. ActivityComplexDescription
+
+
+
+
+
+
+
ActivityComplexDescription
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
Activity Complex
+
+
+
Reference:
+
INSPIRE Data Specifications – Base Models – Activity Complex, version 1.0 [DS-D2.10.3]
+
+
+
Definition:
+
Additional information about an activity complex, including its description, address, contact and related parties.
+
+
+
+
+
+
+
+
+
5.4.2.4.4. Area
+
+
+
+
+
+
+
Area
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
Units of Measure
+
+
+
Reference:
+
Geographic information — Conceptual schema language [ISO/TS 19103:2005]
+
+
+
+
+
+
+
+
+
5.4.2.4.5. CadastralParcel
+
+
+
+
+
+
+
CadastralParcel
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
CadastralParcels
+
+
+
Reference:
+
INSPIRE Data specification on Cadastral Parcels [DS-D2.8.I.6]
+
+
+
Definition:
+
Areas defined by cadastral registers or equivalent.
+
+
+
Description:
+
SOURCE [INSPIRE Directive:2007].
+
+NOTE As much as possible, in the INSPIRE context, cadastral parcels should be forming a partition of national territory. Cadastral parcel should be considered as a single area of Earth surface (land and/or water), under homogeneous real property rights and unique ownership, real property rights and ownership being defined by national law (adapted from UN ECE 2004 and WG-CPI, 2006). By unique ownership is meant that the ownership is held by one or several joint owners for the whole parcel.
+
+
+
+
+
+
+
+
+
5.4.2.4.6. Capacity
+
+
+
+
+
+
+
Capacity
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
Activity Complex
+
+
+
Reference:
+
INSPIRE Data Specifications – Base Models – Activity Complex, version 1.0 [DS-D2.10.3]
+
+
+
Definition:
+
A quantification of an actual or potential ability to perform an activity, that typically does not change, does not change often, or does not change to a significant degree.
+
+
+
Description:
+
NOTE Capacity could refer depending of the thematic scope to different concepts included on the legislation as "emission limits", "capacity incineration", "livestock units", "nominal capacity", "objective estimation data", "rate of desulphurization" or "recycling rate".
+
+
+
+
+
+
+
+
+
5.4.2.4.7. ConditionOfFacilityValue
+
+
+
+
+
+
+
ConditionOfFacilityValue
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
Base Types
+
+
+
Reference:
+
INSPIRE Generic Conceptual Model, version 3.4 [DS-D2.5]
+
+
+
Definition:
+
The status of a facility with regards to its completion and use.
+
+
+
+
+
+
+
+
+
5.4.2.4.8. Date
+
+
+
+
+
+
+
Date
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
Date and Time
+
+
+
Reference:
+
Geographic information — Conceptual schema language [ISO/TS 19103:2005]
+
+
+
+
+
+
+
+
+
5.4.2.4.9. EconomicActivityNACEValue
+
+
+
+
+
+
+
EconomicActivityNACEValue
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
Activity Complex
+
+
+
Reference:
+
INSPIRE Data Specifications – Base Models – Activity Complex, version 1.0 [DS-D2.10.3]
+
+
+
Definition:
+
Classification of economic activities according to Eurostat NACE.
+
+
+
+
+
+
+
+
+
5.4.2.4.10. GM_Object
+
+
+
+
+
+
+
GM_Object (abstract)
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
Geometry root
+
+
+
Reference:
+
Geographic information — Spatial schema [ISO 19107:2003]
+
+
+
+
+
+
+
+
+
5.4.2.4.11. GeographicalName
+
+
+
+
+
+
+
GeographicalName
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
Geographical Names
+
+
+
Reference:
+
INSPIRE Data specification on Geographical Names [DS-D2.8.I.3]
+
+
+
Definition:
+
Proper noun applied to a real world entity.
+
+
+
+
+
+
+
+
+
5.4.2.4.12. HydroObject
+
+
+
+
+
+
+
HydroObject (abstract)
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
Hydro - base
+
+
+
Reference:
+
INSPIRE Data specification on Hydrography [DS-D2.8.I.8]
+
+
+
Definition:
+
An identity base for hydrographic (including man-made) objects in the real world.
+
+
+
Description:
+
NOTE Derived 'views' of real-world hydrographic objects are represented through specialisations in other application schemas; all representations of the same real-world object share a common geographic name or hydrographic identifier.
+
+
+
+
+
+
+
+
+
5.4.2.4.13. Identifier
+
+
+
+
+
+
+
Identifier
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
Base Types
+
+
+
Reference:
+
INSPIRE Generic Conceptual Model, version 3.4 [DS-D2.5]
+
+
+
Definition:
+
External unique object identifier published by the responsible body, which may be used by external applications to reference the spatial object.
+
+
+
Description:
+
NOTE1 External object identifiers are distinct from thematic object identifiers.
+
+NOTE 2 The voidable version identifier attribute is not part of the unique identifier of a spatial object and may be used to distinguish two versions of the same spatial object.
+
+NOTE 3 The unique identifier will not change during the life-time of a spatial object.
+
+
+
+
+
+
+
+
+
5.4.2.4.14. Measure
+
+
+
+
+
+
+
Measure
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
ProductionAndIndustrialFacilitiesExtension
+
+
+
Reference:
+
INSPIRE Data specification on Production and Industrial Facilities [DS-D2.8.III.8]
+
+
+
Definition:
+
Declared or measured quantity of any kind of physical entity.
+
+
+
+
+
+
+
+
+
5.4.2.4.15. Number
+
+
+
+
+
+
+
Number (abstract)
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
Numerics
+
+
+
Reference:
+
Geographic information — Conceptual schema language [ISO/TS 19103:2005]
+
+
+
+
+
+
+
+
+
5.4.2.4.16. PT_FreeText
+
+
+
+
+
+
+
PT_FreeText
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
Cultural and linguistic adapdability
+
+
+
Reference:
+
Geographic information — Metadata — XML schema implementation [ISO/TS 19139:2007]
+
+
+
+
+
+
+
+
+
5.4.2.4.17. Permission
+
+
+
+
+
+
+
Permission
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
Activity Complex
+
+
+
Reference:
+
INSPIRE Data Specifications – Base Models – Activity Complex, version 1.0 [DS-D2.10.3]
+
+
+
Definition:
+
Official Decision (formal consent) granting authorization to operate all or part of an Activity Complex, subject to certain conditions which guarantee that the installations or parts of installations on the same site operated by the same operator comply with the requirements fixed by a competent authority. A permit may cover one or more functions and fix parameters of capacity. The term could be extended to other kind of certificates or documents of special relevance depending of the scope (e.g. ISO, EMAS, National Quality Standards, etc). The term may be extended to other kind of certificates or documents of special relevance depending of the scope (e.g. ISO, EMAS, National Quality Standards, etc).
+
+
+
Description:
+
NOTE This terms is referred in several legislative acts as "permit" , "authorization", "development consent" or "exploration permit" among others.
+
+EXAMPLE 1 "…a [written] decision by which the competent authority grants permission to operate all or part of an installation" ;
+EXAMPLE 2 ".. the decision of the competent authority or authorities which entitles the developer to proceed with the project..".
+
+
+
+
+
+
+
+
+
+
+
5.4.3. Externally governed code lists
+
+
The externally governed code lists included in this application schema are specified in the tables in this section.
+
+
+
5.4.3.1. Governance and authoritative source
+
+
+
+
+
+
+
+
+
Code list
+
Governance
+
Authoritative Source
+(incl. version[15]and relevant subset, where applicable)
6.1. Default reference systems, units of measure and grid
+
+
The reference systems, units of measure and geographic grid systems included in this sub-section are the defaults to be used for all INSPIRE data sets, unless theme-specific exceptions and/or additional requirements are defined in section 6.2.
+
+
+
6.1.1. Coordinate reference systems
+
+
6.1.1.1. Datum
+
+
+
+
+
📕
+
+
+
+
IR Requirement
+Annex II, Section 1.2
+Datum for three-dimensional and two-dimensional coordinate reference systems
+
+
+
For the three-dimensional and two-dimensional coordinate reference systems and the horizontal component of compound coordinate reference systems used for making spatial data sets available, the datum shall be the datum of the European Terrestrial Reference System 1989 (ETRS89) in areas within its geographical scope, or the datum of the International Terrestrial Reference System (ITRS) or other geodetic coordinate reference systems compliant with ITRS in areas that are outside the geographical scope of ETRS89. Compliant with the ITRS means that the system definition is based on the definition of the ITRS and there is a well documented relationship between both systems, according to EN ISO 19111.
+
+
+
+
+
+
+
+
6.1.1.2. Coordinate reference systems
+
+
+
+
+
📕
+
+
+
+
IR Requirement
+Annex II, Section 1.3
+Coordinate Reference Systems
+
+
+
Spatial data sets shall be made available using at least one of the coordinate reference systems specified in sections 1.3.1, 1.3.2 and 1.3.3, unless one of the conditions specified in section 1.3.4 holds.
+
+
+
1.3.1. Three-dimensional Coordinate Reference Systems
+
+
+
+
+
Three-dimensional Cartesian coordinates based on a datum specified in 1.2 and using the parameters of the Geodetic Reference System 1980 (GRS80) ellipsoid.
+
+
+
Three-dimensional geodetic coordinates (latitude, longitude and ellipsoidal height) based on a datum specified in 1.2 and using the parameters of the GRS80 ellipsoid.
+
+
+
+
+
1.3.2. Two-dimensional Coordinate Reference Systems
+
+
+
+
+
Two-dimensional geodetic coordinates (latitude and longitude) based on a datum specified in 1.2 and using the parameters of the GRS80 ellipsoid.
+
+
+
Plane coordinates using the ETRS89 Lambert Azimuthal Equal Area coordinate reference system.
+
+
+
Plane coordinates using the ETRS89 Lambert Conformal Conic coordinate reference system.
+
+
+
Plane coordinates using the ETRS89 Transverse Mercator coordinate reference system.
+
+
+
+
+
1.3.3. Compound Coordinate Reference Systems
+
+
+
+
+
+
+
For the horizontal component of the compound coordinate reference system, one of the coordinate reference systems specified in section 1.3.2 shall be used.
+
+
+
For the vertical component, one of the following coordinate reference systems shall be used:
+
+
+
+
+
+
+
+
+
For the vertical component on land, the European Vertical Reference System (EVRS) shall be used to express gravity-related heights within its geographical scope. Other vertical reference systems related to the Earth gravity field shall be used to express gravity-related heights in areas that are outside the geographical scope of EVRS.
+
+
+
For the vertical component in the free atmosphere, barometric pressure, converted to height using ISO 2533:1975 International Standard Atmosphere, or other linear or parametric reference systems shall be used. Where other parametric reference systems are used, these shall be described in an accessible reference using EN ISO 19111-2:2012.
+
+
+
For the vertical component in marine areas where there is an appreciable tidal range (tidal waters), the Lowest Astronomical Tide (LAT) shall be used as the reference surface.
+
+
+
For the vertical component in marine areas without an appreciable tidal range, in open oceans and effectively in waters that are deeper than 200 meters, the Mean Sea Level (MSL) or a well-defined reference level close to the MSL shall be used as the reference surface.
+
+
+
+
+
1.3.4. Other Coordinate Reference Systems
+
+
+
Exceptions, where other coordinate reference systems than those listed in 1.3.1, 1.3.2 or 1.3.3 may be used, are:
+. Other coordinate reference systems may be specified for specific spatial data themes.
+
+
+
+
+
For regions outside of continental Europe, Member States may define suitable coordinate reference systems.
+
+
+
+
+
The geodetic codes and parameters needed to describe these other coordinate reference systems and to allow conversion and transformation operations shall be documented and an identifier shall be created in a coordinate systems register established and operated by the Commission, according to EN ISO 19111 and ISO 19127.
+The Commission shall be assisted by the INSPIRE Commission expert group in the maintenance and update of the coordinate systems register.
+
+
+
+
+
+
+
+
6.1.1.3. Display
+
+
+
+
+
📕
+
+
+
+
IR Requirement
+Annex II, Section 1.4
+Coordinate Reference Systems used in the View Network Service
+
+
+
For the display of spatial data sets with the view network service as specified in Regulation No 976/2009, at least the coordinate reference systems for two-dimensional geodetic coordinates (latitude, longitude) shall be available.
+
+
+
+
+
+
+
+
6.1.1.4. Identifiers for coordinate reference systems
+
+
+
+
+
📕
+
+
+
+
IR Requirement
+Annex II, Section 1.5
+Coordinate Reference System Identifiers
+
+
+
+
+
Coordinate reference system parameters and identifiers shall be managed in one or several common registers for coordinate reference systems.
+
+
+
Only identifiers contained in a common register shall be used for referring to the coordinate reference systems listed in this Section.
+
+
+
+
+
+
+
+
+
These Technical Guidelines propose to use the http URIs provided by the Open Geospatial Consortium as coordinate reference system identifiers (see identifiers for the default CRSs in the INSPIRE coordinate reference systems register). These are based on and redirect to the definition in the EPSG Geodetic Parameter Registry (http://www.epsg-registry.org/).
+
+
+
+
+
+
📒
+
+
+
+
TG Requirement 1
+
+
+
The identifiers listed in the INSPIRE coordinate reference systems register (https://inspire.ec.europa.eu/crs) shall be used for referring to the coordinate reference systems used in a data set.
+
+
+
+
+
+
+
NOTE CRS identifiers may be used e.g. in:
+
+
+
+
+
data encoding,
+
+
+
data set and service metadata, and
+
+
+
requests to INSPIRE network services.
+
+
+
+
+
+
+
6.1.2. Temporal reference system
+
+
+
+
+
📕
+
+
+
+
IR Requirement
+Article 11
+Temporal Reference Systems
+
+
+
+
+
The default temporal reference system referred to in point 5 of part B of the Annex to Commission Regulation (EC) No 1205/2008 ([16]) shall be used, unless other temporal reference systems are specified for a specific spatial data theme in Annex II.
+
+
+
+
+
+
+
+
+
NOTE 1 Point 5 of part B of the Annex to Commission Regulation (EC) No 1205/2008 (the INSPIRE Metadata IRs) states that the default reference system shall be the Gregorian calendar, with dates expressed in accordance with ISO 8601.
+
+
+
NOTE 2 ISO 8601 Data elements and interchange formats – Information interchange – Representation of dates and times is an international standard covering the exchange of date and time-related data. The purpose of this standard is to provide an unambiguous and well-defined method of representing dates and times, so as to avoid misinterpretation of numeric representations of dates and times, particularly when data is transferred between countries with different conventions for writing numeric dates and times. The standard organizes the data so the largest temporal term (the year) appears first in the data string and progresses to the smallest term (the second). It also provides for a standardized method of communicating time-based information across time zones by attaching an offset to Coordinated Universal Time (UTC).
+
+
+
EXAMPLE 1997 (the year 1997), 1997-07-16 (16th July 1997), 1997-07-16T19:20:3001:00 (16th July 1997, 19h 20' 30'', time zone: UTC1)
+
+
+
+
6.1.3. Units of measure
+
+
+
+
+
📕
+
+
+
+
IR Requirement
+Article 12
+Other Requirements & Rules
+
+
+
(…)
+
+
+
+
+
All measurement values shall be expressed using SI units or non-SI units accepted for use with the International System of Units, unless specified otherwise for a specific spatial data theme or type.
+
+
+
+
+
+
+
+
+
+
+
6.2. Theme-specific requirements and recommendations
+
+
There are no theme-specific requirements or recommendations on reference systems and grids.
+
+
+
+
+
+
+
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 Agricultural and Aquaculture Facilities (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 Agricultural and Aquaculture Facilities (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 Agricultural and Aquaculture Facilities (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 3 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 3 – Data quality elements used in the spatial data theme Agricultural and Aquaculture Facilities
+
+
+
+
+
+
+
+
+
+
+
+
Section
+
Data quality element
+
Data quality sub-element
+
Definition
+
Evaluation Scope
+
+
+
7.1.1
+
Completeness
+
Omission
+
data absent from the dataset, as described by the scope
+
dataset
+
+
+
7.1.2
+
Logical consistency
+
Conceptual consistency
+
adherence to rules of the conceptual schema
+
dataset
+
+
+
7.1.3
+
Logical consistency
+
Domain consistency
+
adherence of values to the value domains
+
dataset
+
+
+
7.1.4
+
Positional accuracy
+
Absolute or external accuracy
+
closeness of reported coordinate values to values accepted as or being true
+
spatial object type
+
+
+
7.1.5
+
Thematic accuracy
+
Classification correctness
+
comparison of the classes assigned to features or their attributes to a universe of discourse
Where it is impossible to express the evaluation of a data quality element in a quantitative way, the evaluation of the element should be expressed with a textual statement as a data quality descriptive result.
+
+
+
+
+
+
+
7.1.1. Completeness – Omission
+
+
+
+
+
📘
+
+
+
+
Recomendation 8
+
+
+
Omission should be evaluated and documented using Rate of missing items as specified in the tables below.
+
+
+
+
+
+
+
+
+
+
+
+
+
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
+
Information contained on provided datasets could only show a constrained set of elements because of different causes as Geo-reference issues, Thematic Scope Constraints or Data Quality and Accuracy.
+
+
+
Evaluation scope
+
data set
+
+
+
Reporting scope
+
data set
+
+
+
Parameter
+
Calculation Method: Real, Estimated.
+
+
+
Data quality value type
+
Value type for reporting a data quality result. A data quality value type shall be provided for a data quality result. Examples include Boolean, Real, Integer, Ratio (numerator of type integer : denominator of type integer), Percentage, Measure(s) (value(s) unit(s)), Ratio
+
+
+
Data quality value structure
+
Single value
+
+
+
Source reference
+
ISO/DIS 19157 Geographic information – Data quality
+
+
+
Example
+
+
Legislation requirements establish limits (e.g Combustion Capacity, Number of Animals,..) to the Entities to be registered on Thematic Data Sets.
+
+
+
Limits and conditions on the Accuracy requested by the legislation (e.g. REGULATION (EC) No 1166/2008 )
The Application Schema conformance class of the Abstract Test Suite in Annex I defines a number of tests to evaluate the conceptual consistency (tests A.1.1, A.1.2 and A.1.4-A.1.7) of a data set.
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 9
+
+
+
For the tests on conceptual consistency, it is recommended to use the Logical consistency – Conceptual consistency data quality sub-element and the measure Number of items not compliant with the rules of the conceptual schema as specified in the table below.
+
+
+
+
+
+
+
+
+
+
+
+
+
Name
+
+
+
+
Alternative name
+
-
+
+
+
Data quality element
+
logical consistency
+
+
+
Data quality sub-element
+
conceptual consistency
+
+
+
Data quality basic measure
+
error count
+
+
+
Definition
+
count of all items in the dataset that are not compliant with the rules of the conceptual schema
+
+
+
Description
+
If the conceptual schema explicitly or implicitly describes rules, these rules shall be followed. Violations against such rules can be, for example, invalid placement of features within a defined tolerance, duplication of features and invalid overlap of features.
+
+
+
Evaluation scope
+
spatial object / spatial object type
+
+
+
Reporting scope
+
data set
+
+
+
Parameter
+
-
+
+
+
Data quality value type
+
integer
+
+
+
Data quality value structure
+
-
+
+
+
Source reference
+
ISO/DIS 19157 Geographic information – Data quality
+
+
+
Example
+
+
+
+
Measure identifier
+
10
+
+
+
+
+
+
7.1.3. Logical consistency – Domain consistency
+
+
The Application Schema conformance class of the Abstract Test Suite in Annex I defines a number of tests to evaluate the domain consistency (test A.1.3) of a data set.
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 10
+
+
+
For the tests on domain consistency, it is recommended to use the Logical consistency – Domain consistency data quality sub-element and the measure Number of items not in conformance with their value domain as specified in the table below.
+
+
+
+
+
+
+
+
+
+
+
+
+
Name
+
Number of items not in conformance with their value domain
+
+
+
Alternative name
+
-
+
+
+
Data quality element
+
logical consistency
+
+
+
Data quality sub-element
+
domain consistency
+
+
+
Data quality basic measure
+
error count
+
+
+
Definition
+
count of all items in the dataset that are not in conformance with their value domain
+
+
+
Description
+
+
+
+
Evaluation scope
+
spatial object / spatial object type
+
+
+
Reporting scope
+
data set
+
+
+
Parameter
+
-
+
+
+
Data quality value type
+
integer
+
+
+
+
+
+
7.1.4. Positional accuracy – Absolute or external accuracy
+
+
+
+
+
📘
+
+
+
+
Recomendation 11
+
+
+
Absolute or external accuracy should be evaluated and documented using Mean value of positional uncertainties as specified in the tables below.
+
+
+
+
+
+
+
+
+
+
+
+
+
Name
+
Mean value of positional uncertainties
+
+
+
Alternative name
+
-
+
+
+
Data quality element
+
Positional Accuracy
+
+
+
Data quality sub-element
+
Absolute or external accuracy
+
+
+
Data quality basic measure
+
Not applicable
+
+
+
Definition
+
+
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
+
+
For a number of points (N), the measured positions are given as xmi, ymi and zmi coordinates depending on the dimension in which the position of the point is measured. A corresponding set of coordinates, xti, yti and zti, are considered
+to represent the true positions. The errors are calculated as
+
+
+
+
+
+
+
+
The mean positional uncertainties of the horizontal absolute or external
+positions are then calculated as
+
+
+
+
+
+
+
+
A criterion for the establishing of correspondence should also be stated (e.g.
+allowing for correspondence to the closest position, correspondence on
+vertices or along lines). The criterion/criteria for finding the corresponding
+points shall be reported with the data quality evaluation result.
+This data quality measure is different from the standard deviation.
+
+
+
+
Evaluation scope
+
Spatial object : Activity Complex/Holding
+
+
+
Reporting scope
+
data set
+
+
+
Parameter
+
-
+
+
+
Data quality value type
+
Measure
+
+
+
Data quality value structure
+
+
+
+
Source reference
+
ISO/DIS 19157 Geographic information – Data quality
+
+
+
Example
+
+
REGULATION (EC) No 1166/2008 ) on farm structure surveys and the survey on agricultural production methods
+
+
+
"… ANNEX III
+
+
+
List of farm structure survey characteristics
+
+
+
CHARACTERISTICS UNITS/CATEGORIES
+
+
+
+
+
General characteristics
+
+
+
+
Location of the holding
+
+
+
+
Latitude (within an arc of 5 minutes or less) Degrees: Minutes
+
+
+
Longitude (within an arc of 5 minutes or less) Degrees: Minutes …."
GeographicalCoordinate:
+The coordinates of the location of the facility should be
+expressed in longitude and latitude coordinates giving a
+precision of the order of at least 500 meters and
+referring to the geographical centre of the site of the
+facility.
+Required. …"
Classification correctness should be evaluated and documented using Misclassification rate as specified in the tables below.
+
+
+
+
+
+
+
+
+
+
+
+
+
Name
+
Misclassification rate
+
+
+
Alternative name
+
-
+
+
+
Data quality element
+
Thematic accuracy
+
+
+
Data quality sub-element
+
Classification correctness
+
+
+
Data quality basic measure
+
Error rate
+
+
+
Definition
+
number of incorrectly classified features in relation to the number of features that are supposed to be there
+
+
+
Description
+
-
+
+
+
Evaluation scope
+
data set
+
+
+
Reporting scope
+
data set
+
+
+
Parameter
+
-
+
+
+
Data quality value type
+
Real, Percentage, Ratio
+
+
+
Data quality value structure
+
Single value
+
+
+
Source reference
+
ISO/DIS 19157 Geographic information – Data quality
+
+
+
Example
+
Similarity in terms and scopes can derive in incorrect categorizations (E.g A Combustion plant could be consider as "Installation" or Facility- Activity Complex depending on the capacity and size and its emplacement , isolated or as part of a wider Facility).
+
+
+
Measure identifier
+
61
+
+
+
+
+
+
7.1.6. Temporal quality – Temporal validity
+
+
+
+
+
📘
+
+
+
+
Recomendation 13
+
+
+
Temporal validity should be evaluated and documented using Value Domain Conformance Rate as specified in the tables below.
+
+
+
+
+
+
+
+
+
+
+
+
+
Name
+
Value Domain Conformance Rate
+
+
+
Alternative name
+
-
+
+
+
Data quality element
+
Temporal quality
+
+
+
Data quality sub-element
+
Temporal validity
+
+
+
Data quality basic measure
+
Error rate
+
+
+
Definition
+
+
number of items in the dataset that are in conformance with their value
+domain in relation to the total number of items in the dataset
+
+
+
+
Description
+
-
+
+
+
Evaluation scope
+
spatial object type: Activity Complex
+
+
+
Reporting scope
+
data set
+
+
+
Parameter
+
-
+
+
+
Data quality value type
+
-
+
+
+
Data quality value structure
+
Single value
+
+
+
Source reference
+
-
+
+
+
Example
+
Changes in the legal and real world entities through the time line derive in different classifications and registries in different thematic Datasets. This can derive in duplications and updates of entities in datasets. Temporal validity and refresh of data is an important issue.
+
+
+
Measure identifier
+
17
+
+
+
+
+
+
+
7.2. Minimum data quality requirements
+
+
No minimum data quality recommendations are defined.
+
+
+
+
7.3. Recommendation on data quality
+
+
No minimum data quality recommendations are defined.
+
+
+
+
+
+
+
8. Dataset-level metadata
+
+
+
This section specifies dataset-level metadata elements, which should be used for documenting metadata for a complete dataset or dataset series.
+
+
+
NOTE Metadata can also be reported for each individual spatial object (spatial object-level metadata). Spatial object-level metadata is fully described in the application schema(s) (section 5).
+
+
+
For some dataset-level metadata elements, in particular those for reporting data quality and maintenance, a more specific scope can be specified. This allows the definition of metadata at sub-dataset level, e.g. separately for each spatial object type (see instructions for the relevant metadata element).
+
+
+
8.1. Metadata elements defined in INSPIRE Metadata Regulation
+
+
Table 4 gives an overview of the metadata elements specified in Regulation 1205/2008/EC (implementing Directive 2007/2/EC of the European Parliament and of the Council as regards metadata).
+
+
+
The table contains the following information:
+
+
+
+
+
The first column provides a reference to the relevant section in the Metadata Regulation, which contains a more detailed description.
+
+
+
The second column specifies the name of the metadata element.
+
+
+
The third column specifies the multiplicity.
+
+
+
The fourth column specifies the condition, under which the given element becomes mandatory.
+
+
+
+
+
Table 4 – Metadata for spatial datasets and spatial dataset series specified in Regulation 1205/2008/EC
+
+
+
+
+
+
+
+
+
+
+
Metadata Regulation Section
+
Metadata element
+
Multiplicity
+
Condition
+
+
+
+
+
1.1
+
Resource title
+
1
+
+
+
+
1.2
+
Resource abstract
+
1
+
+
+
+
1.3
+
Resource type
+
1
+
+
+
+
1.4
+
Resource locator
+
0..*
+
Mandatory if a URL is available to obtain more information on the resource, and/or access related services.
+
+
+
1.5
+
Unique resource identifier
+
1..*
+
+
+
+
1.7
+
Resource language
+
0..*
+
Mandatory if the resource includes textual information.
+
+
+
2.1
+
Topic category
+
1..*
+
+
+
+
3
+
Keyword
+
1..*
+
+
+
+
4.1
+
Geographic bounding box
+
1..*
+
+
+
+
5
+
Temporal reference
+
1..*
+
+
+
+
6.1
+
Lineage
+
1
+
+
+
+
6.2
+
Spatial resolution
+
0..*
+
Mandatory for data sets and data set series if an equivalent scale or a resolution distance can be specified.
+
+
+
7
+
Conformity
+
1..*
+
+
+
+
8.1
+
Conditions for access and use
+
1..*
+
+
+
+
8.2
+
Limitations on public access
+
1..*
+
+
+
+
9
+
Responsible organisation
+
1..*
+
+
+
+
10.1
+
Metadata point of contact
+
1..*
+
+
+
+
10.2
+
Metadata date
+
1
+
+
+
+
10.3
+
Metadata language
+
1
+
+
+
+
+
+
Generic guidelines for implementing these elements using ISO 19115 and 19119 are available at http://inspire.jrc.ec.europa.eu/index.cfm/pageid/101. The following sections describe additional theme-specific recommendations and requirements for implementing these elements.
+
+
+
8.1.1. Conformity
+
+
The Conformity metadata element defined in Regulation 1205/2008/EC requires to report the conformance with the Implementing Rule for interoperability of spatial data sets and services. In addition, it may be used also to document the conformance to another specification.
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 14
+
+
+
Dataset metadata should include a statement on the overall conformance of the dataset with this data specification (i.e. conformance with all requirements).
+
+
+
+
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 15
+
+
+
The Conformity metadata element should be used to document conformance with this data specification (as a whole), with a specific conformance class defined in the Abstract Test Suite in Annex A and/or with another specification.
+
+
+
+
+
+
+
The Conformity element includes two sub-elements, the Specification (a citation of the Implementing Rule for interoperability of spatial data sets and services or other specification), and the Degree of conformity. The Degree can be Conformant (if the dataset is fully conformant with the cited specification), Not Conformant (if the dataset does not conform to the cited specification) or Not Evaluated (if the conformance has not been evaluated).
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 16
+
+
+
If a dataset is not yet conformant with all requirements of this data specification, it is recommended to include information on the conformance with the individual conformance classes specified in the Abstract Test Suite in Annex A.
+
+
+
+
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 17
+
+
+
If a dataset is produced or transformed according to an external specification that includes specific quality assurance procedures, the conformity with this specification should be documented using the Conformity metadata element.
+
+
+
+
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 18
+
+
+
If minimum data quality recommendations are defined then the statement on the conformity with these requirements should be included using the Conformity metadata element and referring to the relevant data quality conformance class in the Abstract Test Suite.
+
+
+
+
+
+
+
NOTE Currently no minimum data quality requirements are included in the IRs. The recommendation above should be included as a requirement in the IRs if minimum data quality requirements are defined at some point in the future.
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 19
+
+
+
When documenting conformance with this data specification or one of the conformance classes defined in the Abstract Test Suite, the Specification sub-element should be given using the http URI identifier of the conformance class or using a citation including the following elements:
+
+
+
+
+
title: "INSPIRE Data Specification on Agricultural and Aquaculture Facilities – Draft Guidelines – <name of the conformance class>"
+
+
+
date:
+
+
+
+
dateType: publication
+
+
+
date: 2013-12-10
+
+
+
+
+
+
+
+
+
+
+
+
EXAMPLE 1: The XML snippets below show how to fill the Specification sub-element for documenting conformance with the whole data specification on Addresses v3.0.1.
EXAMPLE 2: The XML snippets below show how to fill the Specification sub-element for documenting conformance with the CRS conformance class of the data specification on Addresses v3.0.1.
Following the ISO/DIS 19157 Quality principles, if a data provider has a procedure for the quality management of their spatial data sets then the appropriate data quality elements and measures defined in ISO/DIS 19157 should be used to evaluate and report (in the metadata) the results. If not, the Lineage metadata element (defined in Regulation 1205/2008/EC) should be used to describe the overall quality of a spatial data set.
+
+
+
+
+
+
+
According to Regulation 1205/2008/EC, lineage "is a statement on process history and/or overall quality of the spatial data set. Where appropriate it may include a statement whether the data set has been validated or quality assured, whether it is the official version (if multiple versions exist), and whether it has legal validity. The value domain of this metadata element is free text".
+
+
+
The Metadata Technical Guidelines based on EN ISO 19115 and EN ISO 19119 specifies that the statement sub-element of LI_Lineage (EN ISO 19115) should be used to implement the lineage metadata element.
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 21
+
+
+
To describe the transformation steps and related source data, it is recommended to use the following sub-elements of LI_Lineage:
+
+
+
+
+
For the description of the transformation process of the local to the common INSPIRE data structures, the LI_ProcessStep sub-element should be used.
+
+
+
For the description of the source data the LI_Source sub-element should be used.
+
+
+
+
+
+
+
+
+
NOTE 1 In order to improve the interoperability, domain templates and instructions for using these free text elements (descriptive statements) may be specified here and/or in an Annex of this data specification.
+
+
+
+
8.1.3. Temporal reference
+
+
According to Regulation 1205/2008/EC, at least one of the following temporal reference metadata sub-elements shall be provided: temporal extent, date of publication, date of last revision, date of creation.
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 22
+
+
+
It is recommended that at least the date of the last revision of a spatial data set should be reported using the Date of last revision metadata sub-element.
+
+
+
+
+
+
+
+
+
8.2. Metadata elements for interoperability
+
+
+
+
+
📕
+
+
+
+
IR Requirement
+Article 13
+Metadata required for Interoperability
+
+
+
The metadata describing a spatial data set shall include the following metadata elements required for interoperability:
+
+
+
+
+
Coordinate Reference System: Description of the coordinate reference system(s) used in the data set.
+
+
+
Temporal Reference System: Description of the temporal reference system(s) used in the data set.
+
+
This element is mandatory only if the spatial data set contains temporal information that does not refer to the default temporal reference system.
+
+
+
+
Encoding: Description of the computer language construct(s) specifying the representation of data objects in a record, file, message, storage device or transmission channel.
+
+
+
Topological Consistency: Correctness of the explicitly encoded topological characteristics of the data set as described by the scope.
+
+
This element is mandatory only if the data set includes types from the Generic Network Model and does not assure centreline topology (connectivity of centrelines) for the network.
+
+
+
+
Character Encoding: The character encoding used in the data set.
+
+
This element is mandatory only if an encoding is used that is not based on UTF-8.
+
+
+
+
Spatial Representation Type: The method used to spatially represent geographic information.
+
+
+
+
+
+
+
+
+
These Technical Guidelines propose to implement the required metadata elements based on ISO 19115 and ISO/TS 19139.
+
+
+
The following TG requirements need to be met in order to be conformant with the proposed encoding.
+
+
+
+
+
+
📒
+
+
+
+
TG Requirement 2
+
+
+
Metadata instance (XML) documents shall validate without error against the used ISO 19139 XML schema.
+
+
+
+
+
+
+
NOTE Section 2.1.2 of the Metadata Technical Guidelines discusses the different ISO 19139 XML schemas that are currently available.
+
+
+
+
+
+
📒
+
+
+
+
TG Requirement 3
+
+
+
Metadata instance (XML) documents shall contain the elements and meet the INSPIRE multiplicity specified in the sections below.
+
+
+
+
+
+
+
+
+
+
📒
+
+
+
+
TG Requirement 4
+
+
+
The elements specified below shall be available in the specified ISO/TS 19139 path.
+
+
+
+
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 23
+
+
+
The metadata elements for interoperability should be made available together with the metadata elements defined in the Metadata Regulation through an INSPIRE discovery service.
+
+
+
+
+
+
+
NOTE While this not explicitly required by any of the INSPIRE Implementing Rules, making all metadata of a data set available together and through one service simplifies implementation and usability.
+
+
+
8.2.1. Coordinate Reference System
+
+
+
+
+
+
+
+
Metadata element name
+
Coordinate Reference System
+
+
+
Definition
+
Description of the coordinate reference system used in the dataset.
+
+
+
ISO 19115 number and name
+
13. referenceSystemInfo
+
+
+
ISO/TS 19139 path
+
referenceSystemInfo
+
+
+
INSPIRE obligation / condition
+
mandatory
+
+
+
INSPIRE multiplicity
+
1..*
+
+
+
Data type(and ISO 19115 no.)
+
186. MD_ReferenceSystem
+
+
+
Domain
+
+
To identify the reference system, the referenceSystemIdentifier (RS_Identifier) shall be provided.
+
+
+
NOTE More specific instructions, in particular on pre-defined values for filling the referenceSystemIdentifier attribute should be agreed among Member States during the implementation phase to support interoperability.
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.
Description of the computer language construct that specifies the representation of data objects in a record, file, message, storage device or transmission channel
See B.2.10.4. The property values (name, version, specification) specified in section 5 shall be used to document the default and alternative encodings.
+
+
+
Implementing instructions
+
+
+
+
Example
+
+
name: <Application schema name> GML application schema
+version: version 3.0
+specification: D2.8.III.9 Data Specification on Agricultural and Aquaculture Facilities – Technical Guidelines
The method used to spatially represent geographic information.
+
+
+
ISO 19115 number and name
+
37. spatialRepresentationType
+
+
+
ISO/TS 19139 path
+
+
+
+
INSPIRE obligation / condition
+
Mandatory
+
+
+
INSPIRE multiplicity
+
1..*
+
+
+
Data type (and ISO 19115 no.)
+
B.5.26 MD_SpatialRepresentationTypeCode
+
+
+
Domain
+
+
+
+
Implementing instructions
+
+
Of the values included in the code list in ISO 19115 (vector, grid, textTable, tin, stereoModel, video), only vector, grid and tin should be used.
+
+
+
NOTE Additional code list values may be defined based on feedback from implementation.
+
+
+
+
Example
+
-
+
+
+
Example XML encoding
+
+
+
+
Comments
+
+
+
+
+
+
+
8.2.6. Data Quality – Logical Consistency – Topological Consistency
+
+
See section 8.3.2 for instructions on how to implement metadata elements for reporting data quality.
+
+
+
+
+
8.3. Recommended theme-specific metadata elements
+
+
+
+
+
📘
+
+
+
+
Recomendation 24
+
+
+
The metadata describing a spatial data set or a spatial data set series related to the theme Agricultural and Aquaculture Facilities should comprise the theme-specific metadata elements specified in Table 5.
+
+
+
+
+
+
+
The table contains the following information:
+
+
+
+
+
The first column provides a reference to a more detailed description.
+
+
+
The second column specifies the name of the metadata element.
+
+
+
The third column specifies the multiplicity.
+
+
+
+
+
Table 5 – Optional theme-specific metadata elements for the theme Agricultural and Aquaculture Facilities
+
+
+
+
+
+
+
+
+
+
Section
+
Metadata element
+
Multiplicity
+
+
+
+
+
8.3.1
+
Maintenance Information
+
0..1
+
+
+
8.3.2
+
Logical Consistency – Conceptual Consistency
+
0..*
+
+
+
8.3.2
+
Logical Consistency – Domain Consistency
+
0..*
+
+
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 25
+
+
+
For implementing the metadata elements included in this section using ISO 19115, ISO/DIS 19157 and ISO/TS 19139, the instructions included in the relevant sub-sections should be followed.
+
+
+
+
+
+
+
8.3.1. Maintenance Information
+
+
+
+
+
+
+
+
Metadata element name
+
Maintenance information
+
+
+
Definition
+
Information about the scope and frequency of updating
This is a complex type (lines 143-148 from ISO 19115).
+
+
+
At least the following elements should be used (the multiplicity according to ISO 19115 is shown in parentheses):
+
+
+
+
+
maintenanceAndUpdateFrequency [1]: frequency with which changes and additions are made to the resource after the initial resource is completed / domain value: MD_MaintenanceFrequencyCode:
+
+
+
updateScope [0..*]: scope of data to which maintenance is applied / domain value: MD_ScopeCode
+
+
+
maintenanceNote [0..*]: information regarding specific requirements for maintaining the resource / domain value: free text
+
+
+
+
+
+
Implementing instructions
+
+
+
+
Example
+
+
+
+
Example XML encoding
+
+
+
+
Comments
+
+
+
+
+
+
+
8.3.2. Metadata elements for reporting data quality
+
+
+
+
+
📘
+
+
+
+
Recomendation 26
+
+
+
For reporting the results of the data quality evaluation, the data quality elements, sub-elements and (for quantitative evaluation) measures defined in chapter 7 should be used.
+
+
+
+
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 27
+
+
+
The metadata elements specified in the following sections should be used to report the results of the data quality evaluation. At least the information included in the row "Implementation instructions" should be provided.
+
+
+
+
+
+
+
The first section applies to reporting quantitative results (using the element DQ_QuantitativeResult), while the second section applies to reporting non-quantitative results (using the element DQ_DescriptiveResult).
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 28
+
+
+
If a dataset does not pass the tests of the Application schema conformance class (defined in Annex A), the results of each test should be reported using one of the options described in sections 8.3.2.1 and 8.3.2.2.
+
+
+
+
+
+
+
NOTE 1 If using non-quantitative description, the results of several tests do not have to be reported separately, but may be combined into one descriptive statement.
+
+
+
NOTE 2 The sections 8.3.2.1 and 8.3.2.2 may need to be updated once the XML schemas for ISO 19157 have been finalised.
+
+
+
The scope for reporting may be different from the scope for evaluating data quality (see section 7). If data quality is reported at the data set or spatial object type level, the results are usually derived or aggregated.
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 29
+
+
+
The scope element (of type DQ_Scope) of the DQ_DataQuality subtype should be used to encode the reporting scope.
+
+
+
Only the following values should be used for the level element of DQ_Scope: Series, Dataset, featureType.
+
+
+
If the level is featureType the levelDescription/MDScopeDescription/features element (of type Set< GF_FeatureType>) shall be used to list the feature type names.
+
+
+
+
+
+
+
NOTE In the level element of DQ_Scope, the value featureType is used to denote spatial object type.
+
+
+
8.3.2.1. Guidelines for reporting quantitative results of the data quality evaluation
+
+
+
+
+
+
+
+
Metadata element name
+
See chapter 7
+
+
+
Definition
+
See chapter 7
+
+
+
ISO/DIS 19157 number and name
+
3. report
+
+
+
ISO/TS 19139 path
+
dataQualityInfo/*/report
+
+
+
INSPIRE obligation / condition
+
optional
+
+
+
INSPIRE multiplicity
+
0..*
+
+
+
Data type (and ISO/DIS 19157 no.)
+
Corresponding DQ_xxx subelement from ISO/DIS 19157, e.g. 12. DQ_CompletenessCommission
+
+
+
Domain
+
+
Lines 7-9 from ISO/DIS 19157
+
+
+
+
+
DQ_MeasureReference (C.2.1.3)
+
+
+
DQ_EvaluationMethod (C.2.1.4.)
+
+
+
DQ_Result (C2.1.5.)
+
+
+
+
+
+
Implementing instructions
+
+
+
+
nameOfMeasure
+
+
+
+
+
NOTE This should be the name as defined in Chapter 7.
+
+
+
+
+
evaluationMethodType
+
+
+
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.
+
+
+
+
+
dateTime
+
+
+
+
+
NOTE This should be data or range of dates on which the data quality measure was applied.
+
+
+
+
+
DQ_QuantitativeResult / 64. value
+
+
+
+
+
NOTE The DQ_Result type should be DQ_QuantitativeResult and the value(s) represent(s) the application of the data quality measure (39.) using the specified evaluation method (42-43.)
+
+
+
+
Example
+
See Table E.12 — Reporting commission as metadata (ISO/DIS 19157)
+
+
+
Example XML encoding
+
+
+
+
+
+
+
8.3.2.2. Guidelines for reporting descriptive results of the Data Quality evaluation
+
+
+
+
+
+
+
+
Metadata element name
+
See chapter 7
+
+
+
Definition
+
See chapter 7
+
+
+
ISO/DIS 19157 number and name
+
3. report
+
+
+
ISO/TS 19139 path
+
dataQualityInfo/*/report
+
+
+
INSPIRE obligation / condition
+
optional
+
+
+
INSPIRE multiplicity
+
0..*
+
+
+
Data type (and ISO/DIS 19157 no.)
+
Corresponding DQ_xxx subelement from ISO/DIS 19157, e.g. 12. DQ_CompletenessCommission
+
+
+
Domain
+
+
Line 9 from ISO/DIS 19157
+
+
+
+
+
DQ_Result (C2.1.5.)
+
+
+
+
+
+
Implementing instructions
+
+
+
+
DQ_DescripitveResult / 68. statement
+
+
+
+
+
NOTE The DQ_Result type should be DQ_DescriptiveResult and in the statement (68.) the evaluation of the selected DQ sub-element should be expressed in a narrative way.
+
+
+
+
Example
+
See Table E.15 — Reporting descriptive result as metadata (ISO/DIS 19157)
+
+
+
Example XML encoding
+
+
+
+
+
+
+
+
+
+
+
+
9. Delivery
+
+
+
9.1. Updates
+
+
+
+
+
📕
+
+
+
+
IR Requirement
+Article 8
+Updates
+
+
+
+
+
Member States shall make available updates of data on a regular basis.
+
+
+
All updates shall be made available at the latest 6 months after the change was applied in the source data set, unless a different period is specified for a specific spatial data theme in Annex II.
+
+
+
+
+
+
+
+
+
NOTE In this data specification, no exception is specified, so all updates shall be made available at the latest 6 months after the change was applied in the source data set.
+
+
+
+
9.2. Delivery medium
+
+
According to Article 11(1) of the INSPIRE Directive, Member States shall establish and operate a network of services for INSPIRE spatial data sets and services. The relevant network service types for making spatial data available are:
+
+
+
+
+
view services making it possible, as a minimum, to display, navigate, zoom in/out, pan, or overlay viewable spatial data sets and to display legend information and any relevant content of metadata;
+
+
+
download services, enabling copies of spatial data sets, or parts of such sets, to be downloaded and, where practicable, accessed directly;
+
+
+
transformation services, enabling spatial data sets to be transformed with a view to achieving interoperability.
+
+
+
+
+
NOTE For the relevant requirements and recommendations for network services, see the relevant Implementing Rules and Technical Guidelines[17].
+
+
+
EXAMPLE 1 Through the Get Spatial Objects function, a download service can either download a pre-defined data set or pre-defined part of a data set (non-direct access download service), or give direct access to the spatial objects contained in the data set, and download selections of spatial objects based upon a query (direct access download service). To execute such a request, some of the following information might be required:
+
+
+
+
+
the list of spatial object types and/or predefined data sets that are offered by the download service (to be provided through the Get Download Service Metadata operation),
+
+
+
and the query capabilities section advertising the types of predicates that may be used to form a query expression (to be provided through the Get Download Service Metadata operation, where applicable),
+
+
+
a description of spatial object types offered by a download service instance (to be provided through the Describe Spatial Object Types operation).
+
+
+
+
+
EXAMPLE 2 Through the Transform function, a transformation service carries out data content transformations from native data forms to the INSPIRE-compliant form and vice versa. If this operation is directly called by an application to transform source data (e.g. obtained through a download service) that is not yet conformant with this data specification, the following parameters are required:
+
+
+
Input data (mandatory). The data set to be transformed.
+
+
+
+
+
Source model (mandatory, if cannot be determined from the input data). The model in which the input data is provided.
+
+
+
Target model (mandatory). The model in which the results are expected.
+
+
+
Model mapping (mandatory, unless a default exists). Detailed description of how the transformation is to be carried out.
+
+
+
+
+
+
9.3. Encodings
+
+
The IRs contain the following two requirements for the encoding to be used to make data available.
+
+
+
+
+
+
📕
+
+
+
+
IR Requirement
+Article 7
+Encoding
+
+
+
1. Every encoding rule used to encode spatial data shall conform to EN ISO 19118. In particular, it shall specify schema conversion rules for all spatial object types and all attributes and association roles and the output data structure used.
+
+
+
2. Every encoding rule used to encode spatial data shall be made available.
+
+
+
2a. Every encoding rule used to encode spatial data shall also specify whether and how to represent attributes and association roles for which a corresponding value exists but is not contained in the spatial data sets maintained by a Member State, or cannot be derived from existing values at reasonable costs.
+
+
+
+
+
+
+
NOTE ISO 19118:2011 specifies the requirements for defining encoding rules used for interchange of geographic data within the set of International Standards known as the "ISO 19100 series". An encoding rule allows geographic information defined by application schemas and standardized schemas to be coded into a system-independent data structure suitable for transport and storage. The encoding rule specifies the types of data being coded and the syntax, structure and coding schemes used in the resulting data structure. Specifically, ISO 19118:2011 includes
+
+
+
+
+
requirements for creating encoding rules based on UML schemas,
+
+
+
requirements for creating encoding services, and
+
+
+
requirements for XML-based encoding rules for neutral interchange of data.
+
+
+
+
+
While the IRs do not oblige the usage of a specific encoding, these Technical Guidelines propose to make data related to the spatial data theme Agricultural and Aquaculture Facilities available at least in the default encoding(s) specified in section 9.3.1. In this section, a number of TG requirements are listed that need to be met in order to be conformant with the default encoding(s).
+
+
+
The proposed default encoding(s) meet the requirements in Article 7 of the IRs, i.e. they are conformant with ISO 19118 and (since they are included in this specification) publicly available.
+
+
+
9.3.1. Default Encoding(s)
+
+
9.3.1.1. Specific requirements for GML encoding
+
+
This data specification proposes the use of GML as the default encoding, as recommended in sections 7.2 and 7.3 of [DS-D2.7]. GML is an XML encoding in compliance with ISO 19118, as required in Article 7(1). For details, see [ISO 19136], and in particular Annex E (UML-to-GML application schema encoding rules).
+
+
+
The following TG requirements need to be met in order to be conformant with GML encodings.
+
+
+
+
+
+
📒
+
+
+
+
TG Requirement 5
+
+
+
Data instance (XML) documents shall validate without error against the provided XML schema.
+
+
+
+
+
+
+
NOTE 1 Not all constraints defined in the application schemas can be mapped to XML. Therefore, the following requirement is necessary.
+
+
+
NOTE 2 The obligation to use only the allowed code list values specified for attributes and most of the constraints defined in the application schemas cannot be mapped to the XML sch. They can therefore not be enforced through schema validation. It may be possible to express some of these constraints using other schema or rule languages (e.g. Schematron), in order to enable automatic validation.
+
+
+
+
9.3.1.2. Default encoding(s) for application schema Agricultural and Aquaculture Facilities Model
+
+
Name: Agricultural and Aquaculture Facilities Core Model GML Application Schema
+Version: version 3.0
+Specification: D2.8.III.9 Data Specification on Agricultural and Aquaculture Facilities – Guidelines
+Character set: UTF-8
9.3.1.3. Default encoding(s) for application schema Agricultural and Aquaculture Facilities Extended Model
+
+
Name: Agricultural and Aquaculture Facilities Extended Model GML Application Schema
+Version: version 3.0
+Specification: D2.8.III.9 Data Specification on Agricultural and Aquaculture Facilities – Guidelines
+Character set: UTF-8
Facilities may be considered under INSPIRE scope if they meet with the following criteria:
+
+
+
+
+
Information related with the Activities performed on them shall be provided for the use or the benefit of the public excluding strategic or private information not required by law. It can be used by other administrations or private companies as well.
+
+
+
Based on the INSPIRE principles, the service can be used for environmental issues.
+
+
+
Also, in order to full fill the requirements of the INSPIRE Directive, the information must be available as Digital Data.
+
+
+
+
+
Facilities related data, due to their nature and the wide scope covered, may be captured and served by different data providers at different levels of (mainly) the Public Administration. Due to this fact, it is expected that data will be stored at very different formats, scales and resolutions, covering different sub-sets of data, service types and different modeling approaches, depending on the concrete needs of their correspondent producers and target users.
+
+
+
The Geographical entities covered by the scope of Facilities cover a wide range of profiles and scales. In higher levels of the scale, geographical position is derived from tabular data, gazzeters or manual processing mostly based on Geographical Coordinates. Different Data Sets can follow parallel geo-reference processes to geo-locate same real world entities. In some cases there is no authomatic interconnection through identifiers to establish the connection among datasets which can difficult the merging process or generate duplications or overlaps.
+
+
+
VAT (or fiscal codes) should not be assigned directly to a facility, as the VAT code identifies a legal entity, rather than a spatial entity and it is subject to temporal variations.
+
+
+
+
+
+
+
+
Figure 8 – Range of Scopes covered under "Facilities"
+
+
+
It cannot be expected that a single set of requirements may be established in order to harmonize these theme’s data sets. In consequence, just the following recommendations are proposed:
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 30
+
+
+
Given that it is not expected that all of the available datasets are captured, produced and publicized by a single level of Public Administration Bodies and that it may happen that these bodies may be responsible for just one or several sub-sets of data, not necessarily categorizing the Activities following the NACE Code List, data should be transformed in such a way that at least the main class of the model (linked with Activity Complex) should be categorized by at least one of the Activities listed within the NACE Code List.
+
+
+
+
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 31
+
+
+
If the current thematic Legislative Act fix certain parameters for accuracy in the Geographical location of the entities (Geographical Coordinates), these should be considered as the minimum level of accuracy under INSPIRE (e.g. Location of the Holding under REGULATION (EC) No 1166/2008)
+
+
+
+
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 32
+
+
+
In order to fill the previous recommendation, datasets should be built by setting different layers for each of the main Activities covered (higher level of categorization following the NACE List).
+
+
+
+
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 33
+
+
+
In order to minimize the risk of geometrical and positional incoherence between different datasets Economical Activities, when data about an instance is located by means of GM_Object, it is recommended to choose GM_Point as default.
+
+
+
+
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 34
+
+
+
When data about an instance of Economical Activities is located by means of a point or an address geo-location, this should correspond to the main access point to the space where the service is provided from. Only contrasted geo-located locations against the reality should be provided in order to avoid errors and misunderstandings.
+
+
+
+
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 35
+
+
+
Sets the requirement that point representation areas always must be inside the contour of the real world entity that is describing.
+
+
+
+
+
+
+
+
+
+
11. Portrayal
+
+
+
This clause defines the rules for layers and styles to be used for portrayal of the spatial object types defined for this theme. Portrayal is regulated in Article 14 of the IRs.
+
+
+
+
+
+
📕
+
+
+
+
IR Requirement
+Article 14
+Portrayal
+
+
+
+
+
For the portrayal of spatial data sets using a view network service as specified in Commission Regulation No 976/2009 ([18]), the following shall be available:
+
+
+
+
the layers specified in Annex II for the theme or themes the data set is related to;
+
+
+
for each layer at least a default portrayal style, with as a minimum an associated title and a unique identifier.
+
+
+
+
+
+
+
+
+
+
For each layer, Annex II defines the following:
+
+
+
+
a human readable title of the layer to be used for display in user interface;
+
+
+
the spatial object type(s), or sub-set thereof, that constitute(s) the content of the layer.
+
+
+
+
+
+
+
+
+
+
+
+
In section , the types of layers are defined that are to be used for the portrayal of the spatial object types defined in this specification. A view service may offer several layers of the same type, one for each dataset that it offers data on a specific topic.
+
+
+
NOTE The layer specification in the IRs only contains the name, a human readable title and the (subset(s) of) spatial object type(s), that constitute(s) the content of the layer. In addition, these Technical Guidelines suggest keywords for describing the layer.
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 36
+
+
+
It is recommended to use the keywords specified in section in the Layers Metadata parameters of the INSPIRE View service (see Annex III, Part A, section 2.2.4 in Commission Regulation (EC) No 976/2009).
+
+
+
+
+
+
+
Section 0 specifies one style for each of these layers. It is proposed that INSPIRE view services support this style as the default style required by Article 14(1b).
+
+
+
+
+
+
📒
+
+
+
+
TG Requirement 6
+
+
+
For each layer specified in this section, the styles defined in section 0 shall be available.
+
+
+
+
+
+
+
NOTE The default style should be used for portrayal by the view network service if no user-defined style is specified in a portrayal request for a specific layer.
+
+
+
In section 11.3, further styles can be specified that represent examples of styles typically used in a thematic domain. It is recommended that also these styles should be supported by INSPIRE view services, where applicable.
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 37
+
+
+
In addition, it is recommended that, where applicable, INSPIRE view services also support the styles defined in section 11.3.
+
+
+
+
+
+
+
Where XML fragments are used in the following sections, the following namespace prefixes apply:
+
+
+
+
+
sld="http://www.opengis.net/sld" (WMS/SLD 1.1)
+
+
+
se="http://www.opengis.net/se" (SE 1.1)
+
+
+
ogc="http://www.opengis.net/ogc" (FE 1.1)
+
+
+
+
+
11.1. Layers to be provided by INSPIRE view services
+
+
This clause defines the rules for layers and styles to be used for portrayal of the spatial object types defined for the Agricultural and Aquaculture Facilities theme.
+
+
+
The Agricultural and Aquaculture Facilities theme is represented with four different type map layers:
+
+
+
+
+
Holding: The geographical representation of entities inside which Agricultural and Aquaculture activities are carried out.
+
+
+
Sites: All land at a distinct geographic location under the management control of Holding covering activities, products and services. This includes all infrastructure, equipment and materials;
+
+
+
Abstract Installations: Natural or engineered units or apparatus performing activities which have a technical connection with the activities carried out on that site and which could have an effect on emissions and pollution;
+
+
+
Plots: Independent portion of the land or water surface, clearly delimited, including or matching the limits of the Sites described for a Holding.
For spatial object types whose objects can be further classified using a code list-valued attribute, several layers may be defined. Each of these layers shall include the spatial objects corresponding to one specific code list value. In the definition of such sets of layers in Annexes II-IV,
+
+
+
+
the placeholder <CodeListValue> shall represent the values of the relevant code list, with the first letter in upper case,
+
+
+
the placeholder <human-readable name> shall represent the human-readable name of the code list values;
+
+
+
the spatial object type shall include the relevant attribute and code list, in parentheses;
+
+
+
one example of a layer shall be given.
+
+
+
+
+
+
+
+
+
+
+
+
11.1.1. Layers organisation
+
+
The next hierarchy is recommended to be implemented:
+
+
+
Concerning Holdings: Two types of map layers namely Agricultural Holdings and Aquaculture Holding, one for each based on the NACE activity sub-group (Section A - Second Level).
+
+
+
+
+
A - Agriculture, forestry and fishing
+
+
+
+
A1 -Crop and animal production, hunting and related service activities
+
+
+
+
A1.1 - Growing of non-perennial crops
+
+
+
A1.2 - Growing of perennial crops
+
+
+
A1.3 - Plant propagation
+
+
+
A1.4 - Animal production
+
+
+
A1.5 - Mixed farming
+
+
+
A1.6 - Support activities to agriculture and post-harvest crop activities
+
+
+
A1.7 - Hunting, trapping and related service activities
+
+
+
+
+
+
A2 -Forestry and logging (A2 -Forestry and logging not requiered)
+
+
+
A3 -Fishing and aquaculture
+
+
+
+
A3.1 - Fishing
+
+
+
A3.2 - Aquaculture
+
+
+
+
+
+
+
+
+
+
+
This classification allows distinguish among Agricultural (A-A1) and Aquaculture (A-A3). In a more advanced steps there could be also another level of detail (third level of detail on the NACE hierarchy).
+
+
+
Portrayal is not defined because currently there is not an agreement in the communities about it.
+
+
+
Concerning Sites: Only one type layer. Effectively it could be other map layers based on subset as result of the "Activity classification" applied or derived from the Holding to which are linked.
+
+
+
Concerning Installations: Only one type layer. Effectively it could be other map layers based on subset as result of the extension of Installation (Irrigation, Water Management, Aquaculture).
+
+
+
Concerning Plots: Only one type layer.
+
+
+
Concerning Agri-Building: Only one type layer.
+
+
+
+
+
11.2. Styles to be supported by INSPIRE view services
+
+
11.2.1. Styles for the layer AF.AgriculturalHolding
+
+
+
+
+
+
+
+
Style Name
+
AF.AgriculturalHolding.Default
+
+
+
+
+
Default Style
+
Yes
+
+
+
Style Title
+
Agricultural Holding Default Style
+
+
+
Style Abstract
+
The geometry is rendered as a circle with a size of 3 pixels, with a green (#008000) fill and a black outline (#000000).
+
+
+
Symbology
+
+
+
<sld:NamedLayer>
+ <se:Name> AF.AgriculturalHolding</se:Name>
+ <sld:UserStyle>
+ <se:Name> AF.AgriculturalHolding.Default</se:Name>
+ <sld:IsDefault>1</sld:IsDefault>
+ <se:FeatureTypeStyle version="1.1.0">
+ <se:Description>
+ <se:Title> Agricultural Holding Default Style </se:Title>
+ <se:Abstract>The geometry is rendered as a circle with a size of 3 pixels, with a green (#008000) fill and a black outline (#000000).</se:Abstract>
+ </se:Description>
+ <se:FeatureTypeName> AF.AgriculturalHolding</se:FeatureTypeName>
+ <se:Rule>
+ <se:PointSymbolizer>
+ <se:Geometry>
+ <ogc:PropertyName>Holding:geometry</ogc:PropertyName>
+ </se:Geometry>
+ <se:Graphic/>
+ </se:PointSymbolizer>
+ </se:Rule>
+ </se:FeatureTypeStyle>
+ </sld:UserStyle>
+ </sld:NamedLayer>
+
+
+
+
+
Minimum & maximum scales
+
Open - 1:25 000
+
+
+
+
+
+
11.2.2. Styles for the layer AF.AquacultureHolding
+
+
+
+
+
+
+
+
Style Name
+
AF.AquacultureHolding.Default
+
+
+
+
+
Default Style
+
Yes
+
+
+
Style Title
+
Aquaculture Holding Default Style
+
+
+
Style Abstract
+
The geometry is rendered as a circle with a size of 3 pixels, with a blue fill (#0000FF) and a black outline (#000000).
+
+
+
Symbology
+
+
+
<sld:NamedLayer>
+ <se:Name>AF.AquacultureHolding</se:Name>
+ <sld:UserStyle>
+ <se:Name> AF.AquacultureHolding.Default</se:Name>
+ <sld:IsDefault>1</sld:IsDefault>
+ <se:FeatureTypeStyle version="1.1.0">
+ <se:Description>
+ <se:Title> Aquaculture Holding Default Style </se:Title>
+ <se:Abstract>The geometry is rendered as a circle with a size of 3 pixels, with a blue (#0000FF) fill and a black outline (#000000).</se:Abstract>
+ </se:Description>
+ <se:FeatureTypeName>AF.AquacultureHolding</se:FeatureTypeName>
+ <se:Rule>
+ <se:PointSymbolizer>
+ <se:Geometry>
+ <ogc:PropertyName>Holding:geometry
+ </ogc:PropertyName>
+ </se:Geometry>
+ <se:Graphic/>
+ </se:PointSymbolizer>
+ </se:Rule>
+ </se:FeatureTypeStyle>
+ </sld:UserStyle>
+ </sld:NamedLayer>
+
+
+
+
+
Minimum & maximum scales
+
Open - 1:25 000
+
+
+
+
+
+
11.2.3. Styles for the layer AF.Site
+
+
+
+
+
+
+
+
Style Name
+
AF.Site.Default
+
+
+
+
+
Default Style
+
Yes
+
+
+
Style Title
+
Agricultural and Aquaculture Site Default Style
+
+
+
Style Abstract
+
This layer type is for representation of Agricultural and Aquaculture Sites as Points or Polygons
+
+
+
Symbology
+
+
For Polygon geometry:
+
+
+
+
<sld:NamedLayer>
+ <se:Name> AF.Site</se:Name>
+ <sld:UserStyle>
+ <se:Name>AF.Site.Default</se:Name>
+ <sld:IsDefault>1</sld:IsDefault>
+ <se:FeatureTypeStyle version="1.1.0">
+ <se:Description>
+ <se:Title>Agricultural and Aquaculture Site Default Style</se:Title>
+ <se:Abstract>The geometry is rendered using a 50% grey (#808080) fill and a solid blue (#0000FF) outline with a stroke width of 1 pixel.</se:Abstract>
+ </se:Description>
+ <se:FeatureTypeName>AF.Site</se:FeatureTypeName>
+ <se:Rule>
+ <se:PolygonSymbolizer>
+ <se:Geometry>
+ <ogc:PropertyName>AFSite.geometry</ogc:PropertyName>
+ </se:Geometry>
+ <se:Fill/>
+ <se:Stroke/>
+ </se:PolygonSymbolizer>
+ </se:Rule>
+ </se:FeatureTypeStyle>
+ </sld:UserStyle>
+</sld:NamedLayer>
+
+
+
+
For Point geometry:
+
+
+
+
<sld:NamedLayer>
+ <se:Name>AF.Site</se:Name>
+ <sld:UserStyle>
+ <se:Name> AF.Site.Default</se:Name>
+ <sld:IsDefault>1</sld:IsDefault>
+ <se:FeatureTypeStyle version="1.1.0">
+ <se:Description>
+ <se:Title> Agriculture and Aquaculture Sites Default Style </se:Title>
+ <se:Abstract>The geometry is rendered as a circle with a size of 3 pixels, a 50% grey (#808080) fill and and a solid blue (#0000FF) </se:Abstract>
+ </se:Description>
+ <se:FeatureTypeName>AF.Site</se:FeatureTypeName>
+ <se:Rule>
+ <se:PointSymbolizer>
+ <se:Geometry>
+ <ogc:PropertyName>Site:geometry
+ </ogc:PropertyName>
+ </se:Geometry>
+ <se:Graphic/>
+ </se:PointSymbolizer>
+ </se:Rule>
+ </se:FeatureTypeStyle>
+ </sld:UserStyle>
+ </sld:NamedLayer>
+
+
+
+
+
Minimum & maximum scales
+
1:25.000 – 1:5.000
+
+
+
+
+
+
11.2.4. Styles for the layer AF.AbstractInstallation
+
+
+
+
+
+
+
+
Style Name
+
AF.AbstractInstallation.Default
+
+
+
+
+
Default Style
+
Yes
+
+
+
Style Title
+
Agricultural and Aquaculture Abstract Installation Default Style
+
+
+
Style Abstract
+
The geometry is rendered as a circle with a size of 3 pixels, with a Pink (#FF00FF) fill and a black outline (#000000).
+
+
+
Symbology
+
+
+
<sld:NamedLayer>
+ <se:Name> AF.AbstractInstallation.Default</se:Name>
+ <sld:UserStyle>
+ <se:Name>INSPIRE_Default</se:Name>
+ <sld:IsDefault>1</sld:IsDefault>
+ <se:FeatureTypeStyle version="1.1.0">
+ <se:Description>
+ <se:Title>Agricultural and Aquaculture AbstractInstallation Default Style</se:Title>
+ <se:Abstract> The geometry is rendered as a circle with a size of 3 pixel, with a Pink (#FF00FF) fill and a black outline (#000000)</se:Abstract>
+ </se:Description>
+ <se:FeatureTypeName>AF.AbstractInstallation</se:FeatureTypeName>
+ <se:Rule>
+ <se:PolygonSymbolizer>
+ <se:Geometry>
+ <ogc:PropertyName>AbstractInstallation.geometry</ogc:PropertyName>
+ </se:Geometry>
+ <se:Fill/>
+ <se:Stroke/>
+ </se:PolygonSymbolizer>
+ </se:Rule>
+ </se:FeatureTypeStyle>
+ </sld:UserStyle>
+ </sld:NamedLayer>
+
+
+
+
+
Minimum & maximum scales
+
1:25.000 – 1:1.000
+
+
+
+
+
+
11.2.5. Styles for the layer AF.Plot
+
+
+
+
+
+
+
+
Style Name
+
AF.Plot.Default
+
+
+
+
+
Default Style
+
AF.Plot.Default
+
+
+
Style Title
+
Agricultural and Aquaculture Plot Default Style
+
+
+
Style Abstract
+
The geometry is rendered using a grey (#808080) fill and a solid Yellow (rgb=#FFFF00) outline with a stroke width of 1 pixel.
+
+
+
Symbology
+
+
+
<sld:NamedLayer>
+ <se:Name> AF.Plot.Default</se:Name>
+ <sld:UserStyle>
+ <se:Name>INSPIRE_Default</se:Name>
+ <sld:IsDefault>1</sld:IsDefault>
+ <se:FeatureTypeStyle version="1.1.0">
+ <se:Description>
+ <se:Title>Agricultural and Aquaculture Plot Default Style</se:Title>
+ <se:Abstract>The geometry is rendered using a 50% grey (#808080) fill and a solid Yellow (rgb=#FFFF00) outline with a stroke width of 1 pixel </se:Abstract>
+ </se:Description>
+ <se:FeatureTypeName>AF.Plot</se:FeatureTypeName>
+ <se:Rule>
+ <se:PolygonSymbolizer>
+ <se:Geometry>
+ <ogc:PropertyName>Plot.geometry</ogc:PropertyName>
+ </se:Geometry>
+ <se:Fill/>
+ <se:Stroke/>
+ </se:PolygonSymbolizer>
+ </se:Rule>
+ </se:FeatureTypeStyle>
+ </sld:UserStyle>
+
+
+
+
+
Minimum & maximum scales
+
1:25.000 – 1:5.000
+
+
+
+
+
+
11.2.6. Styles for the layer AF.AgriBuilding
+
+
+
+
+
+
+
+
Style Name
+
AF.AgriBuilding.Default
+
+
+
+
+
Default Style
+
AF.AgriBuilding.Default
+
+
+
Style Title
+
Agricultural and Aquaculture Agribuilding Default Style
+
+
+
Style Abstract
+
The geometry is rendered as a circle with a size of 3 pixels, with a Green (#808000) fill and a black outline (#000000).
+
+
+
Symbology
+
+
+
<sld:NamedLayer>
+ <se:Name> AF.AgriBuilding.Default</se:Name>
+ <sld:UserStyle>
+ <se:Name>INSPIRE_Default</se:Name>
+ <sld:IsDefault>1</sld:IsDefault>
+ <se:FeatureTypeStyle version="1.1.0">
+ <se:Description>
+ <se:Title>Agricultural and Aquaculture AgriBuilding Default Style</se:Title>
+ <se:Abstract> The geometry is rendered as a circle with a size of 3 pixels, with a Green (#808000) fill and a black outline (#000000)</se:Abstract>
+ </se:Description>
+ <se:FeatureTypeName>AF.AgriBuilding</se:FeatureTypeName>
+ <se:Rule>
+ <se:PolygonSymbolizer>
+ <se:Geometry>
+ <ogc:PropertyName>AgriByuilding.geometry</ogc:PropertyName>
+ </se:Geometry>
+ <se:Fill/>
+ <se:Stroke/>
+ </se:PolygonSymbolizer>
+ </se:Rule>
+ </se:FeatureTypeStyle>
+ </sld:UserStyle>
+ </sld:NamedLayer>
[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: Abstract Test Suite - (normative)
+
+
+
+
+
+
+
+
Disclaimer
+
+While this Annex refers to the Commission Regulation (EU) No 1089/2010 of 23 November 2010 implementing Directive 2007/2/EC of the European Parliament and of the Council as regards interoperability of spatial data sets and services, it does not replace the legal act or any part of it.
+
+
+
+
+
The objective of the Abstract Test Suite (ATS) included in this Annex is to help the conformance testing process. It includes a set of tests to be applied on a data set to evaluate whether it fulfils the requirements included in this data specification and the corresponding parts of Commission Regulation No 1089/2010 (implementing rule as regards interoperability of spatial datasets and services, further referred to as ISDSS Regulation). This is to help data providers in declaring the conformity of a data set to the "degree of conformity, with implementing rules adopted under Article 7(1) of Directive 2007/2/EC", which is required to be provided in the data set metadata according to Commission Regulation (EC) No 2008/1205 (the Metadata Regulation).
+
+
+
Part 1 of this ATS includes tests that provide input for assessing conformity with the ISDSS regulation. In order to make visible which requirements are addressed by a specific test, references to the corresponding articles of the legal act are given. The way how the cited requirements apply to AF specification is described under the testing method.
+
+
+
In addition to the requirements included in ISDSS Regulation this Technical guideline contains TG requirements too. TG requirements are technical provisions that need to be fulfilled in order to be conformant with the corresponding IR requirement when the specific technical implementation proposed in this document is used. Such requirements relate for example to the default encoding described in section 9. Part 2 of the ATS presents tests necessary for assessing the conformity with TG requirements.
+
+
+
NOTE Conformance of a data set with the TG requirement(s) included in this ATS implies conformance with the corresponding IR requirement(s).
+
+
+
The ATS is applicable to the data sets thathave been transformed to be made available through INSPIRE download services (i.e. the data returned as a response to the mandatory "Get Spatial Dataset" operation) rather than the original "source" data sets.
+
+
+
The requirements to be tested are grouped in several conformance classes. Each of these classes covers a specific aspect: one conformance class contains tests reflecting the requirements on the application schema, another on the reference systems, etc. Each conformance class is identified by a URI (uniform resource identifier) according to the following pattern:
The results of the tests should be published referring to the relevant conformance class (using its URI).
+
+
+
When an INSPIRE data specification contains more than one application schema, the requirements tested in a conformance class may differ depending on the application schema used as a target for the transformation of the data set. This will always be the case for the application schema conformance class. However, also other conformance classes could have different requirements for different application schemas. In such cases, a separate conformance class is defined for each application schema, and they are distinguished by specific URIs according to the following pattern:
An overview of the conformance classes and the associated tests is given in the table below.
+
+
+
+
+
+
+
+
A.1 Application Schema Conformance Class
+
+
+
+
+
+
+
+
+
A.1.1 Schema element denomination test
+
+
+
A.1.2 Value type test
+
+
+
A.1.3 Value test
+
+
+
A.1.4 Attributes/associations completeness test
+
+
+
A.1.5 Abstract spatial object test
+
+
+
A.1.6 Constraints test
+
+
+
A.1.7 Geometry representation test
+
+
+
+
+
+
A.2 Reference Systems Conformance Class
+
+
+
+
+
+
+
+
+
A.2.1 Datum test
+
+
+
A.2.2 Coordinate reference system test
+
+
+
A.2.3 View service coordinate reference system test
+
+
+
A.2.4 Temporal reference system test
+
+
+
A.2.5 Units of measurements test
+
+
+
+
+
+
A.3 Data Consistency Conformance Class
+
+
+
+
+
+
+
+
+
A.3.1 Unique identifier persistency test
+
+
+
A.3.2 Version consistency test
+
+
+
A.3.3 Life cycle time sequence test
+
+
+
A.3.4 Validity time sequence test
+
+
+
A.3.5 Update frequency test
+
+
+
+
+
+
A.4 Data Quality Conformance Class
+
+
+
A.5 Metadata IR Conformance Class
+
+
+
+
+
+
+
+
+
A.5.1 Metadata for interoperability test
+
+
+
+
+
+
A.6 Information Accessibility Conformance Class
+
+
+
+
+
+
+
+
+
A.6.1 Code list publication test
+
+
+
A.6.2 CRS publication test
+
+
+
A.6.3 CRS identification test
+
+
+
+
+
+
A.7 Data Delivery Conformance Class
+
+
+
+
+
+
+
+
+
A.7.1 Encoding compliance test
+
+
+
+
+
+
A.8 Portrayal Conformance Class
+
+
+
+
+
+
+
+
+
A.8.1 Layer designation test
+
+
+
+
+
+
A.9 Technical Guideline Conformance Class
+
+
+
+
+
+
+
+
+
A.9.1 Multiplicity test
+
+
+
A.9.2 CRS http URI test
+
+
+
A.9.3 Metadata encoding schema validation test
+
+
+
A.9.4 Metadata occurrence test
+
+
+
A.9.5 Metadata consistency test
+
+
+
A.9.6 Encoding schema validation test
+
+
+
A.9.7 Style test
+
+
+
+
+
+
+
+
In order to be conformant to a conformance class, a data set has to pass all tests defined for that conformance class.
+
+
+
In order to be conformant with the ISDSS regulation the inspected data set needs to be conformant to all conformance classes in Part 1. The conformance class for overall conformity with the ISDSS regulation is identified by the URI http://inspire.ec.europa.eu/conformance-class/ir/AF/.
+
+
+
In order to be conformant with the Technical Guidelines, the dataset under inspection needs to be conformant to all conformance classes included both in Part 1 and 2. Chapter 8 describes in detail how to publish the result of testing regarding overall conformity and conformity with the conformance classes as metadata. The conformance class for overall conformity with the Technical Guidelines is identified by the URI http://inspire.ec.europa.eu/conformance-class/tg/AF/x.y.(z).
+
+
+
It should be noted that data providers are not obliged to integrate / decompose the original structure of the source data sets when they deliver them for INSPIRE. It means that a conformant dataset can contain less or more spatial object / data types than specified in the ISDSS Regulation.
+
+
+
A dataset that contains less spatial object and/or data types can be regarded conformant when the corresponding types of the source datasets after the necessary transformations fulfil the requirements set out in the ISDSS Regulation.
+
+
+
A dataset that contain more spatial object and/or data types may be regarded as conformant when
+
+
+
+
+
all the spatial object / data types that have corresponding types in the source dataset after the necessary transformations fulfil the requirements set out in the ISDSS Regulation and
+
+
+
all additional elements of the source model (spatial object types, data types, attributes, constraints and code lists together with their values) do not conflict with any rule defined in the interoperability target specifications defined for any theme within INSPIRE.
+
+
+
+
+
The ATS contains a detailed list of abstract tests. It should be noted that some tests in the Application schema conformance class can be automated by utilising xml schema validation tools. It should be noted that failing such validation test does not necessary reflect non-compliance to the application schema; it may be the results of erroneous encoding.
+
+
+
Each test in this suit follows the same structure:
+
+
+
+
+
Requirement: citation from the legal texts (ISDSS requirements) or the Technical Guidelines (TG requirements);
+
+
+
Purpose: definition of the scope of the test;
+
+
+
Reference: link to any material that may be useful during the test;
+
+
+
Test method: description of the testing procedure.
+
+
+
+
+
According to ISO 19105:2000 all tests in this ATS are basic tests. Therefore, this statement is not repeated each time.
+
+
+
Part 1 - (normative)
+
+
Conformity with Commission Regulation No 1089/2010
Purpose: Verification whether each element of the dataset under inspection carries a name specified in the target application schema(s).
+
+
+
Reference: Art. 3 and Art.4 of Commission Regulation No 1089/2010
+
+
+
Test Method: Examine whether the corresponding elements of the source schema (spatial object types, data types, attributes, association roles and code lists) are mapped to the target schema with the correct designation of mnemonic names.
+
+
+
+
+
NOTE Further technical information is in the Feature catalogue and UML diagram of the application schema(s) in section 5.2.
+
+
+
+
A.1.2. Value type test
+
+
+
+
Purpose: Verification whether all attributes or association roles use the corresponding value types specified in the application schema(s).
+
+
+
Reference: Art. 3, Art.4, Art.6(1), Art.6(4), Art.6(5) and Art.9(1)of Commission Regulation No 1089/2010.
+
+
+
Test Method: Examine whether the value type of each provided attribute or association role adheres to the corresponding value type specified in the target specification.
+
+
+
+
+
NOTE 1 This test comprises testing the value types of INSPIRE identifiers, the value types of attributes and association roles that should be taken from code lists, and the coverage domains.
+
+
+
NOTE 2 Further technical information is in the Feature catalogue and UML diagram of the application schema(s) in section 5.2.
+
+
+
+
A.1.3. Value test
+
+
+
+
Purpose: Verify whether all attributes or association roles whose value type is a code list take the values set out therein.
+
+
+
Reference: Art.4 (3) of Commission Regulation No 1089/2010.
+
+
+
Test Method: When an attribute / association role has a code list as its type, compare the values of each instance with those provided in the application schema. To pass this tests any instance of an attribute / association role
+
+
+
+
shall take only values explicitly specified in the code list when the code list’s extensibility is "none".
+
+
+
shall take only a value explicitly specified in the code list or shall take a value that is narrower (i.e. more specific) than those explicitly specified in the application schema when the code list’s extensibility is "narrower".
+
+
+
+
+
+
+
+
NOTE 1 This test is not applicable to code lists with extensibility "open" or "any".
+
+
+
NOTE 2 When a data provider only uses code lists with narrower (more specific values) this test can be fully performed based on internal information.
+
+
+
+
A.1.4. Attributes/associations completeness test
+
+
+
+
Purpose: Verification whether each instance of spatial object type and data types include all attributes and association roles as defined in the target application schema.
+
+
+
Reference: Art. 3, Art.4(1), Art.4(2), and Art.5(2) of Commission Regulation No 1089/2010.
+
+
+
Test Method: Examine whether all attributes and association roles defined for a spatial object type or data type are present for each instance in the dataset.
+
+
+
+
+
NOTE 1 Further technical information is in the Feature catalogue and UML diagram of the application schema(s) in section 5.2.
+
+
+
NOTE 2 For all properties defined for a spatial object, a value has to be provided if it exists in or applies to the real world entity – either the corresponding value (if available in the data set maintained by the data provider) or the value of void. If the characteristic described by the attribute or association role does not exist in or apply to the real world entity, the attribute or association role does not need to be present in the data set.
+
+
+
+
A.1.5. Abstract spatial object test
+
+
+
+
Purpose: Verification whether the dataset does NOT contain abstract spatial object / data types defined in the target application schema(s).
+
+
+
Reference: Art.5(3) of Commission Regulation No 1089/2010
+
+
+
Test Method: Examine that there are NO instances of abstract spatial object / data types in the dataset provided.
+
+
+
+
+
NOTE Further technical information is in the Feature catalogue and UML diagram of the application schema(s) in section 5.2.
+
+
+
+
A.1.6. Constraints test
+
+
+
+
Purpose: Verification whether the instances of spatial object and/or data types provided in the dataset adhere to the constraints specified in the target application schema(s).
+
+
+
Reference: Art. 3, Art.4(1), and Art.4(2) of Commission Regulation No 1089/2010.
+
+
+
Test Method: Examine all instances of data for the constraints specified for the corresponding spatial object / data type. Each instance shall adhere to all constraints specified in the target application schema(s).
+
+
+
+
+
NOTE Further technical information is in the Feature catalogue and UML diagram of the application schema(s) in section 5.2.
+
+
+
+
A.1.7. Geometry representation test
+
+
+
+
Purpose: Verification whether the value domain of spatial properties is restricted as specified in the Commission Regulation No 1089/2010.
+
+
+
Reference: Art.12(1), Annex III Section 9 of Commission Regulation No 1089/2010
+
+
+
Test Method Check whether all spatial properties only use 0, 1 and 2-dimensional geometric objects that exist in the right 2-, 3- or 4-dimensional coordinate space, and where all curve interpolations respect the rules specified in the reference documents.
+
+
+
+
+
NOTE Further technical information is in OGC Simple Feature spatial schema v1.2.1 [06-103r4].
Purpose: Verify whether each instance of a spatial object type is given with reference to one of the (geodetic) datums specified in the target specification.
+
+
+
Reference: Annex II Section 1.2 of Commission Regulation No 1089/2010
+
+
+
Test Method: Check whether each instance of a spatial object type specified in the application schema(s) in section 5 has been expressed using:
+
+
+
+
the European Terrestrial Reference System 1989 (ETRS89) within its geographical scope; or
+
+
+
the International Terrestrial Reference System (ITRS) for areas beyond the ETRS89 geographical scope; or
+
+
+
other geodetic coordinate reference systems compliant with the ITRS. Compliant with the ITRS means that the system definition is based on the definition of ITRS and there is a well-established and described relationship between both systems, according to the EN ISO 19111.
+
+
+
+
+
+
+
+
NOTE Further technical information is given in Section 6 of this document.
+
+
+
+
A.2.2. Coordinate reference system test
+
+
+
+
Purpose: Verify whether the two- and three-dimensional coordinate reference systems are used as defined in section 6.
+
+
+
Reference: Section 6 of Commission Regulation 1089/2010.
+
+
+
Test Method: Inspect whether the horizontal and vertical components of coordinates one of the corresponding coordinate reference system has been:
+
+
+
+
Three-dimensional Cartesian coordinates based on a datum specified in 1.2 and using the parameters of the Geodetic Reference System 1980 (GRS80) ellipsoid.
+
+
+
Three-dimensional geodetic coordinates (latitude, longitude and ellipsoidal height) based on a datum specified in 1.2 and using the parameters of the GRS80 ellipsoid.
+
+
+
Two-dimensional geodetic coordinates (latitude and longitude) based on a datum specified in 1.2 and using the parameters of the GRS80 ellipsoid.
+
+
+
Plane coordinates using the ETRS89 Lambert Azimuthal Equal Area coordinate reference system.
+
+
+
Plane coordinates using the ETRS89 Lambert Conformal Conic coordinate reference system.
+
+
+
Plane coordinates using the ETRS89 Transverse Mercator coordinate reference system.
+
+
+
For the vertical component on land, the European Vertical Reference System (EVRS) shall be used to express gravity-related heights within its geographical scope. Other vertical reference systems related to the Earth gravity field shall be used to express gravity-related heights in areas that are outside the geographical scope of EVRS.
+
+
+
For the vertical component in marine areas where there is an appreciable tidal range (tidal waters), the Lowest Astronomical Tide (LAT) shall be used as the reference surface.
+
+
+
For the vertical component in marine areas without an appreciable tidal range, in open oceans and effectively in waters that are deeper than 200 meters, the Mean Sea Level (MSL) or a well-defined reference level close to the MSL shall be used as the reference surface."
+
+
+
For the vertical component in the free atmosphere, barometric pressure, converted to height using ISO 2533:1975 International Standard Atmosphere, or other linear or parametric reference systems shall be used. Where other parametric reference systems are used, these shall be described in an accessible reference using EN ISO 19111-2:2012.
+
+
+
+
+
+
+
+
NOTE Further technical information is given in Section 6 of this document.
+
+
+
+
A.2.3. View service coordinate reference system test
+
+
+
+
Purpose: Verify whether the spatial data set is available in the two dimensional geodetic coordinate system for their display with the INSPIRE View Service.
+
+
+
Reference: Annex II Section 1.4 of Commission Regulation 1089/2010
+
+
+
Test Method: Check that each instance of a spatial object types specified in the application schema(s) in section 5 is available in the two-dimensional geodetic coordinate system
+
+
+
+
+
NOTE Further technical information is given in Section 6 of this document.
+
+
+
+
A.2.4. Temporal reference system test
+
+
+
+
Purpose: Verify whether date and time values are given as specified in Commission Regulation No 1089/2010.
+
+
+
Reference: Art.11(1) of Commission Regulation 1089/2010
+
+
+
Test Method: Check whether:
+
+
+
+
the Gregorian calendar is used as a reference system for date values;
+
+
+
the Universal Time Coordinated (UTC) or the local time including the time zone as an offset from UTC are used as a reference system for time values.
+
+
+
+
+
+
+
+
NOTE Further technical information is given in Section 6 of this document.
+
+
+
+
A.2.5. Units of measurements test
+
+
+
+
Purpose: Verify whether all measurements are expressed as specified in Commission Regulation No 1089/2010.
+
+
+
Reference: Art.12(2) of Commission Regulation 1089/2010
+
+
+
Test Method: Check whether all measurements are expressed in SI units or non-SI units accepted for use with the International System of Units.
+
+
+
+
+
NOTE 1 Further technical information is given in ISO 80000-1:2009.
+
+
+
NOTE 2 Degrees, minutes and seconds are non-SI units accepted for use with the International System of Units for expressing measurements of angles.
Purpose: Verify whether the namespace and localId attributes of the external object identifier remain the same for different versions of a spatial object.
+
+
+
Reference: Art. 9 of Commission Regulation 1089/2010.
+
+
+
Test Method: Compare the namespace and localId attributes of the external object identifiers in the previous version(s) of the dataset with the namespace and localId attributes of the external object identifiers of current version for the same instances of spatial object / data types; To pass the test, neither the namespace, nor the localId shall be changed during the life-cycle of a spatial object.
+
+
+
+
+
NOTE 1 This test can be performed exclusively on the basis of the information available in the database of the data providers.
+
+
+
NOTE 2 When using URI this test includes the verification whether no part of the construct has been changed during the life cycle of the instances of spatial object / data types.
+
+
+
NOTE 3 Further technical information is given in section 14.2 of the INSPIRE Generic Conceptual Model.
+
+
+
+
A.3.2. Version consistency test
+
+
+
+
Purpose: Verify whether different versions of the same spatial object / data type instance belong to the same type.
+
+
+
Reference: Art. 9 of Commission Regulation 1089/2010.
+
+
+
Test Method: Compare the types of different versions for each instance of spatial object / data type
+
+
+
+
+
NOTE 1 This test can be performed exclusively on the basis of the information available in the database of the data providers.
+
+
+
+
A.3.3. Life cycle time sequence test
+
+
+
+
Purpose: Verification whether the value of the attribute beginLifespanVersion refers to an earlier moment of time than the value of the attribute endLifespanVersion for every spatial object / object type where this property is specified.
+
+
+
Reference: Art.10(3) of Commission Regulation 1089/2010.
+
+
+
Test Method: Compare the value of the attribute beginLifespanVersion with attribute endLifespanVersion. The test is passed when the beginLifespanVersion value is before endLifespanVersion value for each instance of all spatial object/data types for which this attribute has been defined.
+
+
+
+
+
NOTE 1 This test can be performed exclusively on the basis of the information available in the database of the data providers.
+
+
+
+
A.3.4. Validity time sequence test
+
+
+
+
Purpose: Verification whether the value of the attribute validFrom refers to an earlier moment of time than the value of the attribute validTo for every spatial object / object type where this property is specified.
+
+
+
Reference: Art.12(3) of Commission Regulation 1089/2010.
+
+
+
Test Method: Compare the value of the attribute validFrom with attribute validTo. The test is passed when the validFrom value is before validTo value for each instance of all spatial object/data types for which this attribute has been defined.
+
+
+
+
+
NOTE 1 This test can be performed exclusively on the basis of the information available in the database of the data providers.
+
+
+
+
A.3.5. Update frequency test
+
+
+
+
Purpose: Verify whether all the updates in the source dataset(s) have been transmitted to the dataset(s) which can be retrieved for the AF data theme using INSPIRE download services.
+
+
+
Reference: Art.8 (2) of Commission Regulation 1089/2010.
+
+
+
Test Method: Compare the values of beginning of life cycle information in the source and the target datasets for each instance of corresponding spatial object / object types. The test is passed when the difference between the corresponding values is less than 6 months.
+
+
+
+
+
NOTE 1 This test can be performed exclusively on the basis of the information available in the database of the data providers.
Purpose: Verify whether the metadata for interoperability of spatial data sets and services described in 1089/2010 Commission Regulation have been created and published for each dataset related to the AF data theme.
+
+
+
Reference: Art.13 of Commission Regulation 1089/2010
+
+
+
Test Method: Inspect whether metadata describing the coordinate reference systems, encoding, topological consistency and spatial representation type have been created and published. If the spatial data set contains temporal information that does not refer to the default temporal reference system, inspect whether metadata describing the temporal reference system have been created and published. If an encoding is used that is not based on UTF-8, inspect whether metadata describing the character encoding have been created.
+
+
+
+
+
NOTE Further technical information is given in section 8 of this document.
Purpose: Purpose: Verify whether all additional values used in the data sets for attributes, for which narrower values or any other value than specified in Commission Regulation 1089/2010 are allowed, are published in a register.
+
+
+
Reference: Art.6(3) and Annex III Section 9
+
+
+
Test Method: For each additional value used in the data sets for code list-valued attributes, check whether it is published in a register.
+
+
+
+
+
NOTE Further technical information is given in section 5 of this document.
+
+
+
+
A.6.2. CRS publication test
+
+
+
+
Purpose: Verify whether the identifiers and the parameters of coordinate reference system are published in common registers.
+
+
+
Reference: Annex II Section 1.5
+
+
+
Test Method: Check whether the identifier and the parameter of the CRS used for the dataset are included in a register. .
+
+
+
+
+
NOTE Further technical information is given in section 6 of this document.
+
+
+
+
A.6.3. CRS identification test
+
+
+
+
Purpose: Verify whether identifiers for other coordinate reference systems than specified in Commission Regulation 1089/2010 have been created and their parameters have been described according to EN ISO 19111 and ISO 19127.
+
+
+
Reference: Annex II Section 1.3.4
+
+
+
Test Method: Check whether the register with the identifiers of the coordinate reference systems is accessible.
+
+
+
+
+
NOTE Further technical information is given in section 6 of this document.
Purpose: verify whether each spatial object type has been assigned to the layer designated according to Commission Regulation 1089/2010.
+
+
+
Reference: Art. 14(1), Art14(2) and Annex II Section 9.
+
+
+
Test Method: Check whether data is made available for the view network service using the specified layers respectively:
+
+
+
+
+
+
+
+
+
+
+
+
Layer Name
+
Layer Title
+
Spatial object type
+
+
+
+
+
AF. AgriculturalHolding
+
Agricultural Holding
+
Holding (spatial objects whose activity attribute has the value = "A1 - Crop and animal production, hunting and related service activities" (from the EconomicActivityNACEValue code list) or a narrower value)
+
+
+
AF. AquacultureHolding
+
Aquaculture Holding
+
Holding (spatial objects whose activity attribute has the value "A3 - Fishing and aquaculture activities" (from the EconomicActivityNACEValue code list) or a narrower value)
+
+
+
AF.Site
+
Agricultural and Aquaculture Sites
+
Site
+
+
+
+
+
NOTE Further technical information is given in section 11 of this document.
+
+
+
Part 2 - (informative)
+
+
Conformity with the technical guideline (TG) Requirements
Purpose: Verify whether each instance of an attribute or association role specified in the application schema(s) does not include fewer or more occurrences than specified in section 5.
+
+
+
Reference: Feature catalogue and UML diagram of the application schema(s) in section 5 of this guideline.
+
+
+
Test Method: Examine that the number of occurrences of each attribute and/or association role for each instance of a spatial object type or data type provided in the dataset corresponds to the number of occurrences of the attribute / association role that is specified in the application schema(s) in section 5.
+
+
+
+
+
+
A.9.2. CRS http URI test
+
+
+
+
Purpose: Verify whether the coordinate reference system used to deliver data for INSPIRE network services has been identified by URIs according to the EPSG register.
+
+
+
Reference: Section 6 of this technical guideline
+
+
+
Test Method: Compare the URI of the dataset with the URIs in the table.
+
+
+
+
+
NOTE 1 Passing this test implies the fulfilment of test A6.2
Purpose: Verify whether the metadata follows an XML schema specified in ISO/TS 19139.
+
+
+
Reference: Section 8 of this technical guideline, ISO/TS 19139
+
+
+
Test Method: Inspect whether provided XML schema is conformant to the encoding specified in ISO 19139 for each metadata instance.
+
+
+
+
+
NOTE 1 Section 2.1.2 of the Metadata Technical Guidelines discusses the different ISO 19139 XML schemas that are currently available.
+
+
+
+
A.9.4. Metadata occurrence test
+
+
+
+
Purpose: Verify whether the occurrence of each metadata element corresponds to those specified in section 8.
+
+
+
Reference: Section 8 of this technical guideline
+
+
+
Test Method: Examine the number of occurrences for each metadata element. The number of occurrences shall be compared with its occurrence specified in Section 8:
+
+
+
+
+
NOTE 1 Section 2.1.2 of the Metadata Technical Guidelines discusses the different ISO 19139 XML schema
+
+
+
+
A.9.5. Metadata consistency test
+
+
+
+
Purpose: Verify whether the metadata elements follow the path specified in ISO/TS 19139.
+
+
+
Reference: Section 8 of this technical guideline, ISO/TS 19139
+
+
+
Test Method: Compare the XML schema of each metadata element with the path provide in ISO/TS 19137.
+
+
+
+
+
NOTE 1 This test does not apply to the metadata elements that are not included in ISO/TS 19139.
+
+
+
+
A.9.6. Encoding schema validation test
+
+
+
+
Purpose: Verify whether the provided dataset follows the rules of default encoding specified in section 9 of this document
+
+
+
Reference: section 9 of this technical guideline
+
+
+
Test Method: Inspect whether provided encoding(s) is conformant to the encoding(s) for the relevant application schema(s) as defined in section 9:
+
+
+
+
+
NOTE 1 Applying this test to the default encoding schema described in section 9 facilitates testing conformity with the application schema specified in section 5. In such cases running this test with positive result may replace tests from A1.1 to A1.4 provided in this abstract test suite.
+
+
+
NOTE 2 Using Schematron or other schema validation tool may significantly improve the validation process, because some some complex constraints of the schema cannot be validated using the simple XSD validation process. On the contrary to XSDs Schematron rules are not delivered together with the INSPIRE data specifications. Automating the process of validation (e.g. creation of Schematron rules) is therefore a task and an opportunity for data providers.
+
+
+
+
A.9.7. Style test
+
+
+
+
Purpose: Verify whether the styles defined in section 11.2 have been made available for each specified layer.
+
+
+
Reference: section 11.2.
+
+
+
Test Method: Check whether the styles defined in section 11.2 have been ma
+de available for each specified layer.
+
+
+
+
+
+
+
+
+
+
Annex B: Use cases - (informative)
+
+
+
As mentioned in Annex E of the ""Data Specifications" Methodology for the development of data specifications", the TWG-AF identified several use cases that are hereunder referenced.
+
+
+
B.1. Use case: "Safe Plant and Animal Production"
+
+
B.1.1. Introduction
+
+
A safe agricultural production, of both plant production and animal production is a basic requirement for a safe human food supply in the EU and the Members States., Also the export of agricultural products relies on a safe production and the absence of pest, diseases and contamination of these commodities.
+
+
+
The control and the measurements in case of an outbreak of an infectious animal disease, or pests in plant production is regulated by several EU regulations and national implementations.
+
+
+
In case of an accident which caused air, water or soil pollution, in the contaminated area or the potential contaminated area measurements will be taken to prevent contaminated products to be used for human food, animal feed or other products which can have risks for human health.
+
+
+
E.g Fukushima nuclear incident.
+
+
+
Fuhushima nuclear plant and information related (based on Inspire requirements) would be under the PF TWG. AF should provide information to evaluate the impact on agricultural production (food).
+
+
+
+
+
Farms affected by different levels of radiation.
+
+
+
Traceability of agricultural products. Trucking.
+
+
A delegation from Japan will visit JRC and one of the experts will try to recover information from them about the analysis and cartographical information they are dealing with. Even about the lacks of information they fount.
+
+
+
"Agricultural monitoring and possible interventions surrounding the site" was one of the conclusions proposed after the accident.
+
+
+
Information about Agricultural Facilities could be classified by different levels of detail and urgency:
+
+
+
+
+
Identify which Agricultural/Aquaculture facilities are inside the different level of radiation (e.g buffers or dispersion model plume).
+
+
+
Classify with kind of activities are taking place in order to classify actions and responses to be taken.
+
+
+
Each item produce depending on its nature has different levels of restriction.
+
+
+
Radiation can vary from air to soil and the persistence of each different medium is different. E.g Water sources can influence on the restrictions.
+
+
+
Other kind of information (not confirmed if databases about exists already) could be relevant to define areas of indirect influence. (e.g straw or manure commercialized for other purposes by farms that are under the restriction area). Probably waste legislation or the water framework directive could be requesting information related with this purposes.
+
+
+
About the difference between Site and Holding, is relevant to have access to the distribution of plots (sites) under the control of certain Holdings or companies in order to avoid mixture of material from contaminated areas with other free of radiation effects.
+
+
+
+
+
+
+
+
During a crisis process there are different actions on time. Since minute "0" to "years later" period. Each different period require different information. Each step could define new sources and formats from which information is required.
+
+
+
+
+
Alarm system.
+
+
+
Restrictions.
+
+
+
Historical Control.
+
+
+
+
+
In all these cases it is important to have geographical information available about the agricultural and aquaculture production facilities and production, to support the decisions about the measurements to be taken by the authorities.
+
+
+
In the present situation the geographical information about facilities and production is available but it is divided over many separate databases. In the databases the geographical content is heterogeneous.
+
+
+
To perform a spatial analysis of the treath or the impact of an incident, information of different sources has to be combined. A harmonized geo component and basic information about elements like holdings, sites and installations, buildings and plots is required.
+
+
+
For monitoring various pest and diseases the EU uses model. The quality of the model results can be improved when harmonized detailed information about facilities is made available to these models.nnModels are also used to predict the distribution of infectious deseases and the severity of the outbreak.
+
+
+
Some examples:
+
+
+
Animal diseases:
+The outbreak of aviar influenza, classical swine fever, foot and mouth disease and Bluetongue
+
+
+
Plant pests:
+Bacterial wilt (potatoes), plant seeds infection with harmfull insects and / or virusses
+
+
+
Incidents:
+Contamination with PCBs, metals, dioxine due to a fire incident (zone with air deposition or hydrostructures infected by firefighting water )
+Nuclear Contamination
+Contamination of water infrastructure due to industrial failure or failure of networks
+(watstewaterinstallation and -network failure, industrial proces failure, emergency emission)
+
+
+
Structural:
+Continuous contamination due to emissions into air, surface or groundwater from (previous) production facilities (mining, industry)
Figure 11 – The Fire on a chemical storage and packing plant Moerdijk.
+
+
+
+
+
+
+
+
Figure 12 – The Fire on a chemical storage and packing plant Moerdijk.
+
+
+
+
+
+
+
+
Figure 13 – The investigation report Moerdijk
+
+
+
+
+
+
+
+
Figure 14 – Overview of the10km zone affected by the plume of the fire and the location of the sample points of the RIVM.
+
+
+
+
+
+
+
+
Figure 15 – Relative air concentration, accumuleted over the fire period, and measured over the living level.
+
+
+
+
+
+
+
+
Figure 16 –Locations of grass and brush samples.
+
+
+
+
+
+
+
+
Figure 17 – The temporary restriction zone of the fire Moerdijk. where the crop plants can be contaminated and not suitable for consumption.
+
+
+
+
B.1.2. Use case description: Safe Plant and Animal Production
+
+
Part 1: UML use case diagram
+
+
+
+
+
+
+
+
Part 2: Legislative Background
+
+
+
The background legislations are numerous, in the different aspects of food production and food safety, animal health, plant protection and the environment.
+The EU regulation for registration of bovine animals
+The EU regulation for registration of sheep and goat animals
+The EU regulation for the transport of farm animals
+The EU regulations on animal feed production
+The general food law
+The Seveso directive (only for large agriculture piggery and poultry facilities)
+The EU Water Framework Directive
+The EU regulation 1200/2009 (annual agriculture survey)
+The key issue is the integration of all the data sources based on this broad set of specialized legislations. This key issue is not covered by a single or dedicated (set) of regulation(s)
+
+
+
Part 3: Detailed, structured description of the use case
+
+
+
+
+
+
+
+
+
Use Case Description
+
+
+
+
+
Name
+
Safe Plant and Animal Production.
+
+
+
Priority
+
Medium
+
+
+
Description
+
+
In case of an major accident which caused air, water or soil pollution (temporal or continuous), in the exposed area or the potential contaminated area, measurements will be taken to prevent contaminated products to be used for human food, animal feed or other products which can have risks for human health. Anyway information and uses along a contamination crisis, pass across different stages in which information require can vary.
+
+
+
In all these cases it is important to have geographical information available about the agricultural and aquaculture production facilities and production, to support the decisions about the measurements to be taken by the authorities in each of the different stages of the crisis.
+
+
+
+
Pre-condition
+
The data about AF is available and updated and can be analyzed based on the geographical context.
+
+
+
Flow of Events – Basic Path
+
+
+
Step 1.
+
+
Outbreak:
+
+
+
In case of some disaster the user (Governmental Authorities, Civil Protection,…), collects and process all the relevant data available on the web. The use case deals with disasters like:
+
+
+
Pollution of the natural environment, distributed in natural way by water, air and soil, or artificial by transport vessels, cars, trains, airplanes.
+
+
+
In addition it could be extended to:
+Outbreak of dangerous plant disease
+Outbreak of dangerous animal disease
+
+
+
+
Step 2
+
+
Take Measures:
+
+
+
The data about the emission sources (amounts and categorization) as the geographical location of physical sources could be collected from others or the same dataset.
+
+
+
Also information to evaluate, make calculations or define areas of restriction or under control could be obtained from different thematic areas (INSPIRE themes) or other sources.
+
+
+
AF facilities provide information to define those Agricultural and Aquaculture Facilities that are affected or included under the delimited areas, helping to categorize them against the impact received and the actions to be taken as result of the events.
+
+
+
Information can be also applied to define temporal control and monitoring of those facilities affected.
+
+
+
+
Step 3
+
+
Monitor and evaluate:
+
+
+
The relevant AF datasets will be made available to the responsible authorities who need to support their decisions over information (basically geographical).
+
+
+
The problems and measurements to be taken after the event are no part of the use case but a tool to do it.
+
+
+
They are covered by the veterinarian expert, plant health experts, or any other responsible authority, by example the National Food Authority.
+
+
+
Based on inputs from experts and the analysis and monitoring operations as result of previous steps, information could evolve in different ways to more restrictions and actions or to next steps as the closure of the event.
+
+
+
+
Post-condition
+
+
The relevant data about AF is available for the authorities and can be used for analyses of the threat, and the provide arguments for measurements be taken to fight the threat.
+
+
+
+
End-users
+
+
+
+
Authorities EU-level --. JRC;
+national Min of Agriculture, Water, Environment; regional water authorities, National Food Authority, Nat. Animal Health organisation, Nat. Plant protection organsation
+
+
+
Farmers
+
+
+
Processors of agri and aqua products
+
+
+
Agri service providers and advisors
+
+
+
Citizens and other stakeholders.
+
+
+
+
+
+
Data source: Thematic information for example relating to environmental aspects
+
+
+
Description
+
+
Registrations of livestock (cattle registration, sheep and goat, pigs, poultry) including movements and holdings.
+Registrations managed by animal health organizations.
+The building register (subset agri or aquaculture functions)
+The Licensing authority (environmental license to run an AF facility)
+
+
+
+
Data provider
+
+
Public, Water Authorities, Animal registration authority, Municipalities
+
+
+
Private and public data collection agencies and companies, , consultancy companies, farm animal organizations (breeding society) farm products processors (dairy industry, agri cooperations…)
+
+
+
+
+
+
Part 4: Cross-Thematic Data Requirements
+
+
+
+
+
+
+
+
+
+
TWG
+
Affected?
+
Datasets affected
+
+
+
+
+
Administrative Units (AU)
+
Yes
+
+
+
+
Addresses (AD)
+
Yes
+
+
+
+
Agricultural and Aquaculture Facilities (AF)
+
Yes
+
+
+
+
Area management/restriction/regulation zones and reporting units (AM)
+
Yes (*)
+
+
+
+
Atmospheric conditionsMeteorological geographical features (AC-MF)
+
No
+
+
+
+
Bio-geographical regions Habitats and biotopes Species distribution (BR-HB-SD)
+
No
+
+
+
+
Buildings
+
No (*)
+
+
+
+
Cadastral Parcels (CP)
+
No
+
+
+
+
Coordinate reference systems
+
No
+
+
+
+
Energy Resources
+
No
+
+
+
+
Environmental Monitoring Facilities (EMF)
+
Yes
+
+
+
+
Geographical grid systems
+
No
+
+
+
+
Geographical names (GN)
+
Yes (*)
+
+
+
+
Geology Mineral resources (GE-MR)
+
No
+
+
+
+
Human Health and Safety (HH)
+
Yes (*)
+
+
+
+
Hydrography (HY)
+
Yes (*)
+
+
+
+
LandCover (LC)
+
Yes(*)
+
+
+
+
LandUse (LU)
+
Yes (*)
+
+
+
+
Natural Risk Zones
+
Yes (*)
+
+
+
+
Production and industrial facilities (PF)
+
Yes
+
+
+
+
Protected Sites (PS)
+
Yes (*)
+
+
+
+
Soil (SO)
+
Yes (*)
+
+
+
+
Statistical Units Population distribution, demography (SU-PD)
+
Yes (*)
+
+
+
+
TransportNetwork (TN)
+
Yes (*)
+
+
+
+
Utility and governmental services (US)
+
No (*)
+
+
+
+
+
+
+
+
B.2. Use case: "Animal Diseases in Aquaculture"
+
+
B.2.1. Introduction
+
+
In order to contain and control the spread of animal diseases veterinary authorities rely to a system of registration of holdings and traceability of animal movements established for the major farmed species.
+
+
+
In case of an outbreak of a listed disease, veterinary authorities take a series of measures prescribed by the EU legislation to control spread of the disease. These measures are normally applied to a defined geographical area around the outbreak site and to all farms falling within this area. The availability of spatial information for the delineation of the area subjected to restriction measures and for the identification of affected farms is of great importance for the planning, management and reporting of the control measures prescribed by EU legislation.
+
+
+
The use case considered as example in this document is related to Infectious Salmon Anemia (ISA) which is an important infectious viral disease affecting Atlantic Salmon.
+
+
+
The disease was first reported in Norway in 1984, and has since been reported in Canada, Faroe Islands, the USA, Ireland and Scotland. The annual cost of infectious salmon anemia outbreaks among farmed fish was estimated to be $11million (U.S. dollars) in Norway in 1999, $14 million in Canada, and $32 million in Scotland in 1998 – 1999. Recent outbreaks were reported in Shetland (Scotland) in 2008-2009.
+
+
+
+
B.2.2. Description
+
+
In order to deal with outbreaks of Infectious Salmon Anaemia (ISA) the Central Veterinary Administration establishes containment areas subjected to movement restriction measures at a certain radius from an affected farm.
+
+
+
An ordinance is issued establishing that in these areas movement restrictions measures on persons, aquatic animals, equipment and means of transport are applied.
+
+
+
Local veterinary authorities control the implementation of these restriction measures.
+
+
+
Relevant stakeholders of the aquaculture industry and the public are informed about the application of these measures.
+
+
+
The following map shows an example of areas with active movement restriction measures in the Western Isles following various outbreaks of disease in fish and shellfish farms.
+
+
+
+
+
+
+
+
Part 1: UML use case diagram
+
+
+
+
+
+
+
+
Part 2: Legislative Background
+
+
+
In the case of aquaculture Council Directive 2006/88/EC prescribes the following measure to be taken in case of suspicion of outbreak of a listed disease:
+
+
+
+
+
farms or molluscs production areas are placed under official surveillance,
+
+
+
movement to and from the affected farm or area are not allowed and,
+
+
+
epizootic investigation are initiated.
+
+
+
+
+
After the epidemiological investigation if the outbreak of the disease is confirmed:
+
+
+
+
+
the farm or mollusc farming area is declared infected,
+
+
+
a containment area including protection zone and surveillance zone is established and,
+
+
+
according to the type of disease a series of control measures including movements' restrictions, compulsory slaughter and disinfection of infected farms are implemented to reduce and prevent the spread of the disease.
+
+
+
+
+
In order to allow the identification of aquaculture facilities the Directive 2006/88/EC prescribes that the competent authorities should keep registers of authorized aquaculture production businesses. For each aquaculture production business the register should contain in addition to address and contact details, information on the production type, health status and the geographical position of the farm. In addition, Commission Decision 2008/392/EC, in order to facilitate the interoperability of information between Member States, prescribes that national registers of aquaculture production businesses should be made available through an internet-based information page.
+
+
+
In relation to ISA, Commission Decision 2003/466/EC prescribes that control zones should be drawn in a circle with a radius at least 5 km or of at least one tidal excursion, centered on the infected farm and surveillance zones or an equivalent area determined according to appropriate hydrodynamic or epidemiological data.
+
+
+
Definitions used in the legislation:
+
+
+
'production area' (*) means any freshwater, sea, estuarine, continental or lagoon area containing natural beds of molluscs or sites used for the cultivation of molluscs, and from which molluscs are taken;
+
+
+
'farm' means any premises, enclosed area, or installation operated by an aquaculture production business (AF holding) in which aquaculture animals are reared with a view to their being placed on the market, with the exception of those where wild aquatic animals harvested or caught for the purpose of human consumption are temporarily kept awaiting slaughter without being fed; It would be related with the Site as is described on the AF Data Model.
+
+
+
'epidemiological unit' (*) means a group of aquatic animals that share approximately the same risk of exposure to a disease agent within a defined location. This risk may be because they share a common aquatic environment, or because management practices make it likely that a disease agent in one group of animals would quickly spread to another group of animals;
+
+
+
'containment area' means an area around an infected farm or mollusc farming area where disease control measures are applied with the purpose of preventing the spread of the disease;
+
+
+
'zone' means a precise geographical area (*) with a homogeneous hydrological system comprising part of a water catchment area from the source(s) to a natural or artificial barrier that prevents the upward migration of aquatic animals from lower stretches of the water catchment area, an entire water catchment area from its source(s) to its estuary, or more than one water catchment area, including their estuaries, due to the epidemiological link between the catchment areas through the estuary.
+
+
+
() AF Model doesn’t refer to "areas" but includes all the information related at a Holding - Site level.*
+
+
+
Part 3: Detailed, structured description of the use case
+
+
+
+
+
+
+
+
+
Use Case Description
+
+
+
+
+
Name
+
Animal disease in aquaculture
+
+
+
Priority
+
Medium
+
+
+
Description
+
Control of the spread of a disease in an aquaculture holdings through the application of restriction measures in a defined area
+
+
+
Pre-condition
+
An outbreak of a disease listed is confirmed. Following the confirmation of an outbreak the Central Veterinary Authority issues an administrative notice indicating the boundaries of the area where restriction measures will be applied.
+
+
+
Flow of Events – Basic Path
+
+
+
Step 1
+
The Central Veterinary Authority Spatial publishes spatial information on the affected area using a web map portal.
+
+
+
Step 2
+
The local veterinary authorities extract from the web map portal a list of aquaculture sites falling within the affected area to enforce control measures. They extract information on holding addresses, type of production, species kept to plan inspections for each site within the affected area.
+
+
+
Post-condition
+
—
+
+
+
Flow of Events – Alternative Paths
+
+
+
Step 2
+
An aquaculture business verifies if movement of live fish with a given are permitted by looking in the web map portal. They enter information about name and address of the trading partner (holding) and the web portal will show all the sites owned by the given holding and if present the areas with active restriction movement restriction measures.
+
+
+
Data set: Aquaculture sites
+
+
+
Description
+
Public register of aquaculture sites established under Directive 2006/88/EC
+
+
+
Data provider
+
National Veterinary Authorities
+
+
+
Geographic scope
+
National
+
+
+
Thematic scope
+
Agricultural and Aquaculture Facilities (AF),
+
+
+
Scale, resolution
+
Scale relevant to the application
+
+
+
Delivery
+
Local Veterinary Authorities, Public, Aquaculture enterprises
+
+
+
Data set: Restricted areas
+
+
+
Description
+
Areas subjected to disease control measures established in an administrative notice.
+
+
+
Data provider
+
National Veterinary Authorities
+
+
+
Geographic scope
+
National
+
+
+
Thematic scope
+
Area management/restriction/regulation zones and reporting units (AM)
+
+
+
Scale, resolution
+
Scale relevant to the application
+
+
+
Delivery
+
Local Veterinary Authorities, Public, Aquaculture enterprises
+
+
+
+
+
Part 4: Cross-Thematic Data Requirements
+
+
+
+
+
+
+
+
+
+
TWG
+
Affected?
+
Datasets affected
+
+
+
+
+
Addresses (AD)
+
No
+
+
+
+
Agricultural and aquacultural facilities (AF)
+
Yes
+
+
+
+
Area management/restriction/regulation zones and reporting units (AM)
+
Yes
+
+
+
+
Atmospheric conditionsMeteorological geographical features (AC-MF)
+
No
+
+
+
+
Bio-geographical regions Habitats and biotopes Species distribution (BR-HB-SD)
+
No
+
+
+
+
Buildings
+
No
+
+
+
+
Cadastral Parcels (CP)
+
No
+
+
+
+
Coordinate reference systems
+
Yes
+
+
+
+
Energy Resources
+
No
+
+
+
+
Environmental Monitoring Facilities (EMF)
+
Yes (*)
+
+
+
+
Geographical grid systems
+
Yes
+
+
+
+
Geographical names (GN)
+
Yes
+
+
+
+
Geology Mineral resources (GE-MR)
+
No
+
+
+
+
Human Health and Safety (HH)
+
No
+
+
+
+
Hydrography (HY)
+
Yes
+
+
+
+
LandCover (LC)
+
No
+
+
+
+
LandUse (LU)
+
No
+
+
+
+
Natural Risk Zones
+
No
+
+
+
+
Production and industrial facilities (PF)
+
Yes
+
+
+
+
Protected Sites (PS)
+
No
+
+
+
+
Soil (SO)
+
No
+
+
+
+
Statistical Units Population distribution, demography (SU-PD)
+
No
+
+
+
+
TransportNetwork (TN)
+
No
+
+
+
+
Utility and governmental services (US)
+
No
+
+
+
+
+
+
+
+
B.3. Use case: "Official controls in mollusk production areas"
+
+
B.3.1. Introduction
+
+
The production of molluscs is subject official controls to ensure food safety and prevent contamination from water pollution and from the accumulation of toxins linked to Harmful Algal Blooms (HAB).
+
+
+
The use of spatial information is needed for the classification of production areas, for the planning of controls, for the monitoring and implementation of the controls and for the communication to producers and other interested parties of the results of the controls and of possible restriction measures.
+
+
+
+
B.3.2. Description
+
+
The CA has to fix the location, boundaries and classification of the mollusc production areas.
+
+
+
In order to classify an area the CA:
+
+
+
+
+
makes an inventory of the sources of pollution of human or animal origin likely to be a source of contamination for the production area;
+
+
+
examines the quantities of organic pollutants which are released during the different periods of the year, according to the seasonal variations of both human and animal populations in the catchment area, rainfall readings, waste water treatment, etc.;
+
+
+
determines the characteristics of the circulation of pollutants by virtue of current patterns, bathymetry and the tidal cycle in the production area.
+
+
+
+
+
Similar sets of spatial information are used on yearly basis to evaluate the risk of contamination for existing mollusc farms and to determine the sampling frequencies and sampling sites.
+
+
+
The CA monitors the implementation of the programme to take appropriate decisions on the production area if the results of the analysis are negative.
+
+
+
To inform producers about the results of the monitoring programme the CA regularly publishes maps and information showing for each production area the list of authorised sites, the sampling site with the results of the latest analysis and the administrative decisions about the classification and closures of the area.
+
+
+
In the example below the Irish Marine Institute through the Irish Spatial Data Exchange provides datasets and maps for locations along the Irish coastline where commercial shellfish harvesting takes place. The figure shows an example of authorized shellfish production area, with sample points for bio-toxin and phytoplankton samples.
+
+
+
+
+
+
+
+
Part 1: UML Case Diagram
+
+
+
+
+
+
+
+
Part 2: Legislative Background
+
+
+
Regulation 854/2004 on official controls on products of animal origin requires that bivalve mollusc are taken from classified production areas.
+
+
+
The areas are classified in one of the following categories according to the level of faecal contamination:
+
+
+
+
+
Class A areas from which live bivalve molluscs may be collected for direct human consumption.
+
+
+
Class B areas from which live bivalve molluscs may be collected, but placed on the market for human consumption only after treatment in a purification centre or after relaying so as to meet the health standards
+
+
+
Class C areas from which live bivalve molluscs may be collected but placed on the market only after relaying over a long period so as to meet the health standards
+
+
+
+
+
Classified areas should be periodically monitored according to sampling programme to check for:
+
+
+
+
+
the microbiological quality of live bivalve mollusc in relation to the production and relaying areas;
+
+
+
the presence of toxin-producing plankton in production and relaying waters and biotoxins in live bivalve mollusc; and
+
+
+
the presence of chemical contaminants in live bivalve molluscs.
+
+
+
+
+
The geographical distribution of the sampling points and the sampling frequency must ensure that the results of the analysis are as representative as possible for the area considered.
+
+
+
The sampling plan should take into account possible variations in the presence of plankton containing marine biotoxins and likely variation in faecal contamination.
+
+
+
If the results of the sampling programme show that health standards are exceeded or if there is a risk for human health, the production area is closed or re-classified.
+
+
+
The competent authorities must establish and keep up to date and communicate to interested parties a list of approved production and relaying areas, with details of their location, boundaries, classification and possible closures.
+
+
+
Definitions in the legislation (see Council Directive 2006/88/EC):
+
+
+
'mollusc farming area' means a production area or relaying area in which all aquaculture production businesses operate under a common biosecurity system;
+
+
+
'production area' means any freshwater, sea, estuarine, continental or lagoon area containing natural beds of molluscs or sites used for the cultivation of molluscs, and from which molluscs are taken;
+
+
+
Part.3: Detailed Structured description of the Use Case
+
+
+
+
+
+
+
+
+
Use Case Description
+
+
+
+
+
Name
+
Official controls in mollusc production areas
+
+
+
Priority
+
Medium
+
+
+
Description
+
The CA monitors the implementation of the sampling program on the quality of mollusc and water and informs the public and stakeholders of the results.
+
+
+
Pre-condition
+
The CA has established mollusc production area and a sampling program.
+
+
+
Flow of Events – Basic Path
+
+
+
Step 1.
+
Select from the geo portal an authorised mollusc production area.
+
+
+
Step 2
+
Show sampling points and aquaculture sites in the mollusc production area.
+
+
+
Step 3
+
Extract for the sampling points the list of samples taken for shellfish and water and the results of analyses for given temporal interval.
+
+
+
Flow of Events – Alternative Paths
+
+
+
Step 3
+
Show active management restriction measures for the given production area
+
+
+
Post-condition
+
+
+
+
Data set: Aquaculture sites
+
+
+
Description
+
Public register of aquaculture sites established under Directive 2006/88/EC
+
+
+
Data provider
+
National Veterinary Authorities
+
+
+
Geographic scope
+
National
+
+
+
Thematic scope
+
Agricultural and aquacultural facilities (AF)
+
+
+
Scale, resolution
+
Scale relevant to the application
+
+
+
Delivery
+
Local Veterinary Authorities, Public, Aquaculture enterprises
+
+
+
Data set: Restricted areas
+
+
+
Description
+
Authorised areas for mollusc production and their classification (Regulation 854/2004)
+
+
+
Data provider
+
National Veterinary Authorities
+
+
+
Geographic scope
+
National
+
+
+
Thematic scope
+
Area management/restriction/regulation zones and reporting units (AM)
+
+
+
Scale, resolution
+
Scale relevant to the application
+
+
+
Delivery
+
Local Veterinary Authorities, Public, Aquaculture enterprises
+
+
+
Data set: Water quality and food safety sampling
+
+
+
Description
+
The sites were samples under official water the quality monitoring and shellfish programme are taken
+
+
+
Data provider
+
Environmental laboratories (water quality) and food safety laboratories (shellfish)
The table below includes recommended values that may be used by data providers. Before creating new terms, please check if one of them can be used.
+
+
+
+
+
+
+
+
+
surfaceIrrigation
+
+
+
+
+
+
+
+
+
Name:
+
surface Irrigation
+
+
+
Definition:
+
Leading the water along the ground, either by flooding the whole area or leading the water along small furrows between the crops, using gravity as a force.
+
+
+
+
+
+
+
sprinklerIrrigation
+
+
+
+
+
+
+
+
+
Name:
+
sprinkler Irrigation
+
+
+
Definition:
+
Irrigation the plants by propelling the water under high pressure as rain over the parcels.
+
+
+
+
+
+
+
dropIrrigation
+
+
+
+
+
+
+
+
+
Name:
+
drop Irrigation
+
+
+
Definition:
+
Irrigation the plants by placing the water low by the plants drop by drop or with micro sprinklers or by forming fog-like conditions.
+
+
+
+
+
+
+
+
PlotActivityValue
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
PlotActivityValue
+
+
+
Definition:
+
The economic activity executed on the plot, as coded accoring to EU regulation (EC) 1200/2009, annex II, chapter 2. (codes 2.01 - 2.04.07 and 2.06.03 - 2.06.04).
The table below includes recommended values that may be used by data providers. Before creating new terms, please check if one of them can be used.
+
+
+
+
+
+
+
+
+
2_01_01
+
+
+
+
+
+
+
+
+
Name:
+
2_01_01_Cereals for the production of grain (including seed)
+
+
+
Definition:
+
All areas of cereals harvested dry for grain, regardless of use, shall be recorded here (including cereals used for renewable energy production).
+
+
+
+
+
+
+
2_01_01_01
+
+
+
+
+
+
+
+
+
Name:
+
2_01_01_01_Common wheat and spelt
+
+
+
Definition:
+
Triticum aestivum L. emend. Fiori et Paol., Triticum spelta L. and Triticum monococcum L.
+
+
+
+
+
+
+
2_01_01_02
+
+
+
+
+
+
+
+
+
Name:
+
2_01_01_02_Durum wheat
+
+
+
Definition:
+
Triticum durum Desf.
+
+
+
+
+
+
+
2_01_01_03
+
+
+
+
+
+
+
+
+
Name:
+
2_01_01_03_Rye
+
+
+
Definition:
+
Secale cereale L., including mixtures of rye and other cereals sown in the autumn (maslin).
+
+
+
+
+
+
+
2_01_01_04
+
+
+
+
+
+
+
+
+
Name:
+
2_01_01_04_Barley
+
+
+
Definition:
+
Hordeum vulgare L.
+
+
+
+
+
+
+
2_01_01_05
+
+
+
+
+
+
+
+
+
Name:
+
2_01_01_05_Oats
+
+
+
Definition:
+
Avena sativa L., including mixtures of oats and other cereals sown in the spring.
+
+
+
+
+
+
+
2_01_01_06
+
+
+
+
+
+
+
+
+
Name:
+
2_01_01_06_Grain maize
+
+
+
Definition:
+
Maize (Zea mays L.) harvested for grain.
+
+
+
+
+
+
+
2_01_01_07
+
+
+
+
+
+
+
+
+
Name:
+
2_01_01_07_Rice
+
+
+
Definition:
+
Oryza sativa L.
+
+
+
+
+
+
+
2_01_01_99
+
+
+
+
+
+
+
+
+
Name:
+
2_01_01_99_Other cereals for the production of grain
+
+
+
Definition:
+
Cereals sown in pure crops, harvested dry for grain, and that are not recorded elsewhere under the previous items.
+
+
+
+
+
+
+
2_01_02
+
+
+
+
+
+
+
+
+
Name:
+
2_01_02_Dried pulses and protein crops for the production of grain (including seed and mixtures of cereals and pulses)
+
+
+
Definition:
+
Crops sown and harvested mainly for their protein content.
+
+
+
Description:
+
All areas of dried pulses and protein crops harvested dry for grain, regardless of use, shall be recorded here (including crops used for renewable energy production).
+
+
+
+
+
+
+
2_01_02_01
+
+
+
+
+
+
+
+
+
Name:
+
2_01_02_01_Dried pulses and protein crops of which peas, field beans and sweet lupins
+
+
+
Definition:
+
Pisum sativum L., Vicia faba L., Lupinus spp., sown in pure crops, harvested dry for grain.
+
+
+
+
+
+
+
2_01_03
+
+
+
+
+
+
+
+
+
Name:
+
2_01_03_Potatoes (including early potatoes and seed potatoes)
+
+
+
Definition:
+
Solanum tuberosum L.
+
+
+
+
+
+
+
2_01_04
+
+
+
+
+
+
+
+
+
Name:
+
2_01_04_Sugar beet (excluding seed)
+
+
+
Definition:
+
Beta vulgaris L. intended for the sugar industry and alcohol production (including energy production).
+
+
+
+
+
+
+
2_01_05
+
+
+
+
+
+
+
+
+
Name:
+
2_01_05_Fodder roots and brassicas (excluding seed)
+
+
+
Definition:
+
Fodder beet (Beta vulgaris L.) and plants of the Brassicae family harvested mainly for animal feed, regardless whether it is the root or the stem, and other plants cultivated mainly for their roots for fodder, not mentioned elsewhere.
+
+
+
+
+
+
+
2_01_06
+
+
+
+
+
+
+
+
+
Name:
+
2_01_06_Industrial crops
+
+
+
Definition:
+
Crops that are normally not sold directly for consumption because they need to be industrially processed prior to final use.
+
+
+
Description:
+
All harvested areas of industrial crops, regardless of use, shall be recorded here (including crops used for renewable energy production).
+
+
+
+
+
+
+
2_01_06_01
+
+
+
+
+
+
+
+
+
Name:
+
2_01_06_01_Tobacco
+
+
+
Definition:
+
Nicotiana tabacum L.
+
+
+
+
+
+
+
2_01_06_02
+
+
+
+
+
+
+
+
+
Name:
+
2_01_06_02_Hops
+
+
+
Definition:
+
Humulus lupulus L.
+
+
+
+
+
+
+
2_01_06_03
+
+
+
+
+
+
+
+
+
Name:
+
2_01_06_03_Cotton
+
+
+
Definition:
+
Gossypium spp., harvested for fibre as well as for oil-seeds.
+
+
+
+
+
+
+
2_01_06_04
+
+
+
+
+
+
+
+
+
Name:
+
2_01_06_04_Rape and turnip rape
+
+
+
Definition:
+
Brassica napus L. (partim) and Brassica rapa L. var. sylvestris (Lam.) Briggs, grown for the production of oil, harvested as dry grains.
+
+
+
+
+
+
+
2_01_06_05
+
+
+
+
+
+
+
+
+
Name:
+
2_01_06_05_Sunflower
+
+
+
Definition:
+
Helianthus annuus L., harvested as dry grains.
+
+
+
+
+
+
+
2_01_06_06
+
+
+
+
+
+
+
+
+
Name:
+
2_01_06_06_Soya
+
+
+
Definition:
+
Glycine max L. Merril, harvested as dry grains.
+
+
+
+
+
+
+
2_01_06_07
+
+
+
+
+
+
+
+
+
Name:
+
2_01_06_07_Linseed (oil flax)
+
+
+
Definition:
+
Linum usitatissimum L., varieties grown mainly for producing oil, harvested as dry grains.
+
+
+
+
+
+
+
2_01_06_08
+
+
+
+
+
+
+
+
+
Name:
+
2_01_06_08_Other oil seed crops
+
+
+
Definition:
+
Other crops grown mainly for their oil content, harvested as dry grains, which are not mentioned elsewhere.
+
+
+
+
+
+
+
2_01_06_09
+
+
+
+
+
+
+
+
+
Name:
+
2_01_06_09_Flax
+
+
+
Definition:
+
Linum usitatissimum L., varieties grown mainly for producing fibre.
+
+
+
+
+
+
+
2_01_06_10
+
+
+
+
+
+
+
+
+
Name:
+
2_01_06_10_Hemp
+
+
+
Definition:
+
Cannabis sativa L.
+
+
+
+
+
+
+
2_01_06_11
+
+
+
+
+
+
+
+
+
Name:
+
2_01_06_11_Other fibre crops
+
+
+
Definition:
+
Other plants grown mainly for their fibre content, not mentioned elsewhere.
+
+
+
+
+
+
+
2_01_06_12
+
+
+
+
+
+
+
+
+
Name:
+
2_01_06_12_Aromatic plants, medicinal and culinary plants
+
+
+
Definition:
+
Plants or parts of plants for pharmaceutical purposes, perfume manufacture or human consumption.
+
+
+
Description:
+
Culinary plants are distinguished from vegetables in that they are used in small amounts and provide flavour rather than substance to food.
+
+
+
+
+
+
+
2_01_06_99
+
+
+
+
+
+
+
+
+
Name:
+
2_01_06_99_Other industrial crops not mentioned elsewhere
+
+
+
Definition:
+
Other industrial crops that have not been mentioned elsewhere.
+
+
+
Description:
+
Areas of crops used exclusively for renewable energy production are included.
+
+
+
+
+
+
+
2_01_07
+
+
+
+
+
+
+
+
+
Name:
+
2_01_07_Fresh vegetables, melons and strawberries of which:
+
+
+
+
+
+
+
2_01_07_01
+
+
+
+
+
+
+
+
+
Name:
+
2_01_07_01_Outdoor or under low (not accessible) protective cover
+
+
+
Definition:
+
Fresh vegetables, melons and strawberries, outdoor or under low (non-accessible) cover.
+
+
+
+
+
+
+
2_01_07_01_01
+
+
+
+
+
+
+
+
+
Name:
+
2_01_07_01_01_Open field
+
+
+
Definition:
+
Fresh vegetables, melons and strawberries grown on arable land in rotation with other agricultural crops.
+
+
+
+
+
+
+
2_01_07_01_02
+
+
+
+
+
+
+
+
+
Name:
+
2_01_07_01_02_Market gardening
+
+
+
Definition:
+
Fresh vegetables, melons and strawberries grown on arable land in rotation with other horticultural crops.
+
+
+
+
+
+
+
2_01_07_02
+
+
+
+
+
+
+
+
+
Name:
+
2_01_07_02_Under glass or other (accessible) protective cover
+
+
+
Definition:
+
Crops, which for the whole of their period of growth or for the predominant part of it are covered by greenhouses or fixed or mobile high cover (glass or rigid or flexible plastic).
+
+
+
+
+
+
+
2_01_08
+
+
+
+
+
+
+
+
+
Name:
+
2_01_08_Flowers and ornamental plants (excluding nurseries)
+
+
+
+
+
+
+
2_01_08_01
+
+
+
+
+
+
+
+
+
Name:
+
2_01_08_01_Outdoor or under low (not accessible) protective cover
+
+
+
Definition:
+
Flowers and ornamental plants (excluding nurseries), outdoor or under low (not accessible) protective cover.
+
+
+
+
+
+
+
2_01_08_02
+
+
+
+
+
+
+
+
+
Name:
+
2_01_08_02_Under glass or other (accessible) protective cover
+
+
+
Definition:
+
Flowers and ornamental plants (excluding nurseries), which for the whole of their period of growth or for the predominant part of it are covered by greenhouses or fixed or mobile high cover (glass or rigid or flexible plastic).
+
+
+
+
+
+
+
2_01_09
+
+
+
+
+
+
+
+
+
Name:
+
2_01_09_Plants harvested green
+
+
+
Definition:
+
All 'green' arable crops intended mainly for animal feed, grown in rotation with other crops and occupying the same parcel for less than five years (annual or multiannual fodder crops).
+
+
+
Description:
+
Green crops used for renewable energy production are included. Crops not used on the holding but sold, either for direct use on other agricultural holdings or to industry, are included.
+
+
+
+
+
+
+
2_01_09_01
+
+
+
+
+
+
+
+
+
Name:
+
2_01_09_01_Temporary grass
+
+
+
Definition:
+
Grass plants for grazing, hay or silage included as a part of a normal crop rotation, lasting at least one crop year and less than five years, sown with grass or grass mixtures. The areas are broken up by ploughing or other tilling or the plants are destroyed by other means such as by herbicides before they are sown again.
+
+
+
Description:
+
Mixtures of predominantly grass plants and other forage crops (usually leguminous), grazed, harvested green or as dried hay are included here.
+
+
+
+
+
+
+
2_01_09_02
+
+
+
+
+
+
+
+
+
Name:
+
2_01_09_02_Other plants harvested green
+
+
+
Definition:
+
Other annual or multiannual (less than five years) fodder crops.
+
+
+
+
+
+
+
2_01_09_02_01
+
+
+
+
+
+
+
+
+
Name:
+
2_01_09_02_01_Green maize
+
+
+
Definition:
+
All forms of maize (Zea mays L.) grown mainly for silage, which is not harvested for grain (whole cob, parts of or whole plant).
+
+
+
Description:
+
This includes green maize directly consumed by animals (without silage) and whole cobs (grain, rachis, husk) harvested for feedstuff or silage as well as for renewable energy production.
+
+
+
+
+
+
+
2_01_09_02_02
+
+
+
+
+
+
+
+
+
Name:
+
2_01_09_02_02_Leguminous plants
+
+
+
Definition:
+
Leguminous plants grown and harvested green as the whole plant mainly for forage.
+
+
+
Description:
+
Mixtures of predominantly leguminous (normally > 80 %) forage crops and grass plants, harvested green or as dried hay are included here.
+
+
+
+
+
+
+
2_01_09_02_99
+
+
+
+
+
+
+
+
+
Name:
+
2_01_09_02_99_Other plants harvested green not mentioned elsewhere
+
+
+
Definition:
+
Other arable crops intended mainly for animal fodder, harvested green, not mentioned elsewhere.
+
+
+
+
+
+
+
2_01_10
+
+
+
+
+
+
+
+
+
Name:
+
2_01_10_Arable land seed and seedlings
+
+
+
Definition:
+
Areas producing seeds and seedlings for sale, excluding cereals, rice, pulses, potatoes and oil seeds.
+
+
+
+
+
+
+
2_01_11
+
+
+
+
+
+
+
+
+
Name:
+
2_01_11_Other arable land crops
+
+
+
Definition:
+
Arable crops not included elsewhere.
+
+
+
+
+
+
+
2_01_12
+
+
+
+
+
+
+
+
+
Name:
+
2_01_12_Fallow land
+
+
+
Definition:
+
All arable land included in the crop rotation system, whether worked or not, but with no intention to produce a harvest for the duration of a crop year.
+
+
+
Description:
+
The essential characteristic of fallow land is that it is left to recover, normally for the whole of a crop year.
+
+
+
+
+
+
+
2_02
+
+
+
+
+
+
+
+
+
Name:
+
2_02_Kitchen gardens
+
+
+
Definition:
+
Areas devoted to the cultivation of agricultural products intended for self-consumption by the holder and his household, normally separated off from the rest of the agricultural land, and recognisable as kitchen gardens.
+
+
+
Description:
+
Fallow land may be:
+
+
+
+
+
+
+
2_03
+
+
+
+
+
+
+
+
+
Name:
+
2_03_Permanent grassland
+
+
+
Definition:
+
Land used permanently (for five years or more) to grow herbaceous forage crops, through cultivation (sown) or naturally (self-seeded), and that is not included in the crop rotation on the holding.
+
+
+
Description:
+
1. bare land bearing no crops at all;
+
+
+
+
+
+
+
2_03_01
+
+
+
+
+
+
+
+
+
Name:
+
2_03_01_Permanent grassland Pasture and meadow, excluding rough grazings
+
+
+
Definition:
+
Permanent pasture on good or medium quality soils. These areas can normally be used for intensive grazing.
+
+
+
Description:
+
2. land with spontaneous natural growth, which may be used as feed or ploughed in;
+
+
+
+
+
+
+
2_03_02
+
+
+
+
+
+
+
+
+
Name:
+
2_03_02_Permanent grassland Rough grazings
+
+
+
Definition:
+
Low yielding permanent grassland, usually on low quality soil, for example on hilly land and at high altitudes, usually unimproved by fertiliser, cultivation, reseeding or drainage.
+
+
+
Description:
+
3. land sown exclusively for the production of green manure (green fallow).
+
+
+
+
+
+
+
2_03_03
+
+
+
+
+
+
+
+
+
Name:
+
2_03_03_Permanent grassland no longer used for production purposes and eligible for the payment of subsidies
+
+
+
Definition:
+
Areas of permanent grassland and meadows no longer used for production purposes which, in line with Regulation (EC) No 1782/2003 or, where applicable, the most recent legislation, are maintained in good agricultural and environmental condition and are eligible for financial support.
+
+
+
Description:
+
Only occasional surplus products coming from this area are sold off from the holding. All areas from which products are consistently sold on the market belong under other items, even if part of the production is consumed by the holder and his household.
+
+
+
+
+
+
+
2_04
+
+
+
+
+
+
+
+
+
Name:
+
2_04_Permanent crops
+
+
+
Definition:
+
Crops not grown in rotation, other than permanent grassland, which occupy the soil for a long period and yield crops over several years.
+
+
+
Description:
+
The land can be used for grazing or mown for silage, hay or used for renewable energy production.
+
+
+
+
+
+
+
2_04_01
+
+
+
+
+
+
+
+
+
Name:
+
2_04_01_Fruit and berry plantations
+
+
+
Definition:
+
Areas containing trees, bushes and perennial berry plants other than strawberries for the production of fruit. Orchards may be of the continuous type with minimum spacing between trees or of the non-continuous type with wide spacing.
+
+
+
+
+
+
+
2_04_01_01
+
+
+
+
+
+
+
+
+
Name:
+
2_04_01_01_Fruit species, of which:
+
+
+
Definition:
+
Fruit tree plantations which are traditionally cropped for producing fruits.
+
+
+
Description:
+
These areas can normally be used only for extensive grazing and are not normally mown or are mown in an extensive manner; they cannot support a large density of animals.
+
+
+
+
+
+
+
2_04_01_01_01
+
+
+
+
+
+
+
+
+
Name:
+
2_04_01_01_01_Fruit of temperate climate zones
+
+
+
Definition:
+
Fruit tree plantations which are traditionally cropped in temperate climates for producing fruits.
+
+
+
+
+
+
+
2_04_01_01_02
+
+
+
+
+
+
+
+
+
Name:
+
2_04_01_01_02_Fruit of subtropical climate zones
+
+
+
Definition:
+
Fruit tree plantations which are traditionally cropped in subtropical climates for producing fruits.
+
+
+
+
+
+
+
2_04_01_02
+
+
+
+
+
+
+
+
+
Name:
+
2_04_01_02_Berry species
+
+
+
Definition:
+
Berry plantations which are traditionally cropped both in temperate and subtropical climates for producing berries.
+
+
+
+
+
+
+
2_04_01_03
+
+
+
+
+
+
+
+
+
Name:
+
2_04_01_03_Nuts
+
+
+
Definition:
+
Nut tree plantations which are traditionally cropped in temperate and subtropical climates.
+
+
+
+
+
+
+
2_04_02
+
+
+
+
+
+
+
+
+
Name:
+
2_04_02_Citrus plantations
+
+
+
Definition:
+
Plantations of Citrus spp.
+
+
+
+
+
+
+
2_04_03
+
+
+
+
+
+
+
+
+
Name:
+
2_04_03_Olive plantations
+
+
+
Definition:
+
Plantations of Olea europea L.
+
+
+
+
+
+
+
2_04_03_01
+
+
+
+
+
+
+
+
+
Name:
+
2_04_03_01_Normally producing table olives
+
+
+
Definition:
+
Plantations of varieties normally grown for producing table olives.
+
+
+
+
+
+
+
2_04_03_02
+
+
+
+
+
+
+
+
+
Name:
+
2_04_03_02_/Normally producing olives for oil production
+
+
+
Definition:
+
Plantations of varieties normally grown for producing olive oil.
+
+
+
+
+
+
+
2_04_04
+
+
+
+
+
+
+
+
+
Name:
+
2_04_04_Vineyards, of which normally producing:
+
+
+
Definition:
+
Plantations of Vitis vinifera L_
+
+
+
+
+
+
+
2_04_04_01
+
+
+
+
+
+
+
+
+
Name:
+
2_04_04_01_Quality wine
+
+
+
Definition:
+
Grape varieties normally grown for the production of wines with a protected designation of origin (PDO) which comply with the requirements (i) of Council Regulation (EC) No 479/2008(1) or, where applicable, the most recent legislation; and (ii) the corresponding national rules.
+
+
+
+
+
+
+
2_04_04_02
+
+
+
+
+
+
+
+
+
Name:
+
2_04_04_02_Other wines
+
+
+
Definition:
+
Grape varieties normally grown for the production of wines other than PDO and PGI wines.
+
+
+
+
+
+
+
2_04_04_03
+
+
+
+
+
+
+
+
+
Name:
+
2_04_04_03_Table grapes
+
+
+
Definition:
+
Grape varieties normally grown for the production of fresh grapes.
+
+
+
+
+
+
+
2_04_04_04
+
+
+
+
+
+
+
+
+
Name:
+
2_04_04_04_Raisins
+
+
+
Definition:
+
Grape varieties normally grown for the production of raisins.
+
+
+
+
+
+
+
2_04_05
+
+
+
+
+
+
+
+
+
Name:
+
2_04_05_Nurseries
+
+
+
Definition:
+
Areas of young ligneous (woody) plants grown in the open air for subsequent transplantation:
+
+
+
Description:
+
Grape varieties normally grown for the production of wines with a protected geographical indication (PGI) which comply with the requirements (i) of Regulation (EC) No 479/2008 or, where applicable, the most recent legislation; and (ii) the corresponding national rules.
+
+
+
+
+
+
+
2_04_06
+
+
+
+
+
+
+
+
+
Name:
+
2_04_06_Other permanent crops
+
+
+
Definition:
+
Open-air permanent crops other than those under the previous heading and in particular those used for plaiting or weaving, harvested generally every year.
+
+
+
+
+
+
+
2_04_06_01
+
+
+
+
+
+
+
+
+
Name:
+
2_04_06_01_Other permanent crops of which Christmas trees(1)
+
+
+
Definition:
+
Trees planted for commercial purposes as Christmas trees on the utilised agricultural area.
+
+
+
+
+
+
+
2_04_07
+
+
+
+
+
+
+
+
+
Name:
+
2_04_07_Permanent crops under glass
+
+
+
Definition:
+
Permanent crops under glass
+
+
+
+
+
+
+
2_06
+
+
+
+
+
+
+
+
+
Name:
+
2_06_Mushrooms, energy crops and genetically modified crops
+
+
+
Description:
+
(a) vine and root-stock nurseries;
+
+
+
+
+
+
+
2_06_01
+
+
+
+
+
+
+
+
+
Name:
+
2_06_01_Mushrooms
+
+
+
Definition:
+
Cultivated mushrooms grown in buildings which have been specially erected or adapted for growing mushrooms, as well as in underground premises, caves and cellars.
+
+
+
Description:
+
(b) fruit tree and berries nurseries;
+
+
+
+
+
+
+
2_06_03
+
+
+
+
+
+
+
+
+
Name:
+
2_06_03_Energy crops (for the production of biofuels or other renewable energy)
+
+
+
Definition:
+
The production area of energy crops benefiting from the following support schemes under Regulation (EC) No 1782/2003:
+
+
+
Description:
+
(c) ornamental nurseries;
+
+
+
+
+
+
+
2_06_03_01
+
+
+
+
+
+
+
+
+
Name:
+
2_06_03_01_Energy crops of which on set-aside area
+
+
+
Definition:
+
The production area of energy crops benefiting of the payment linked to set-aside entitlement when production takes place on set-aside area (Council Regulation (EC) No 1782/2003, Article 55 or 56)
+
+
+
Description:
+
(d) commercial nurseries of forest trees (excluding those for the holding’s own requirements grown within woodland);
+
+
+
+
+
+
+
2_06_04
+
+
+
+
+
+
+
+
+
Name:
+
2_06_04_Genetically modified crops
+
+
+
Definition:
+
'Genetically modified crops (GMC)' mean any organism as defined in Article 2 of Council Directive 2001/18/EC(1) OJ L 106, 17.4.2001, p. 1. (1) or, where applicable, the most recent legislation.
+
+
+
Description:
+
(e) trees and bushes for planting in gardens, parks, at the roadside and on embankments (e.g. hedgerow plants, rose trees and other ornamental bushes, ornamental conifers), including in all cases their stocks and young seedlings.
+
+
+
+
+
+
+
+
TypeOfAgriBuildingValue
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
TypeOfAgriBuildingValue
+
+
+
Definition:
+
The type of building, expressed as a code.
+
+
+
Description:
+
animal housing according to EU regulation (EC) 1200/2009 annex III chapter V, codes 5.01 - 5.03.99.
+2. 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
+
+4. Surveys on unique identifiers and usage of the elements of the spatial and temporal schema,
+
+
+5. 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 Environment Agency
+
+
+6. The Thematic Working Groups have been composed of experts from Austria, Australia, Belgium, Bulgaria, Czech Republic, Denmark, Finland, France, Germany, Hungary, Ireland, Italy, Latvia, Netherlands, Norway, Poland, Romania, Slovakia, Spain, Slovenia, Sweden, Switzerland, Turkey, UK, the European Environment Agency and the European Commission.
+
+
+7. For Annex IIIII, the consultation and testing phase lasted from 20 June to 21 October 2011.
+
+11. Conceptual models related to specific areas (e.g. INSPIRE themes)
+
+
+12. In the case of the Annex IIIII data specifications, the extracted requirements are used to formulate an amendment to the existing Implementing Rule.
+
+
+
\ No newline at end of file
diff --git a/data/af/dataspecification_af.pdf b/data/af/dataspecification_af.pdf
new file mode 100644
index 00000000..d46998da
Binary files /dev/null and b/data/af/dataspecification_af.pdf differ
diff --git a/data/am/dataspecification_am.html b/data/am/dataspecification_am.html
new file mode 100644
index 00000000..4585ca44
--- /dev/null
+++ b/data/am/dataspecification_am.html
@@ -0,0 +1,14854 @@
+
+
+
+
+
+
+
+
+
+
+
+D2.8.III.11 Data Specification on Area Management/Restriction/Regulation Zones and Reporting Units – Technical Guidelines
+
+
+
+
+
+
+
+
+
+
+
+
+
+
INSPIREInfrastructure for Spatial Information in Europe
+
+
D2.8.III.11 Data Specification on Area Management/Restriction/Regulation Zones and Reporting Units – Technical Guidelines
+
+
+
+
+
+
+
+
Title
+
D2.8.III.11 Data Specification on Area Management/Restriction/Regulation Zones and Reporting Units – Technical Guidelines
+
+
+
Creator
+
Temporary MIWP 2021-2024 sub-group 2.3.1
+
+
+
Date of publication
+
2024-01-31
+
+
+
Subject
+
INSPIRE Data Specification for the spatial data theme Area Management/Restriction/Regulation Zones and Reporting Units
+
+
+
Publisher
+
INSPIRE Maintenance and Implementation Group (MIG)
+
+
+
Type
+
Text
+
+
+
Description
+
This document describes the INSPIRE Data Specification for the spatial data theme Area Management/Restriction/Regulation Zones and Reporting Units
Directive 2007/2/EC of the European Parliament and of the Council of 14 March 2007 establishing an Infrastructure for Spatial Information in the European Community (INSPIRE)
+
+
+
+
+
Foreword
+
How to read the document?
+
+
This document describes the "INSPIRE data specification on Area Management/Restriction/Regulation Zones and Reporting Units – Technical Guidelines" version 3.0 as developed by the Thematic Working Group (TWG) TWG AM using both natural and a conceptual schema language.
+
+
+
The data specification is based on a common template[1] used for all data specifications, which has been harmonised using the experience from the development of the Annex I, II and III data specifications.
+
+
+
This document provides guidelines for the implementation of the provisions laid down in the Implementing Rule for spatial data sets and services of the INSPIRE Directive. It also includes additional requirements and recommendations that, although not included in the Implementing Rule, are relevant to guarantee or to increase data interoperability.
+
+
+
Two executive summaries provide a quick overview of the INSPIRE data specification process in general, and the content of the data specification on Area Management/Restriction/Regulation Zones and Reporting Units in particular. We highly recommend that managers, decision makers, and all those new to the INSPIRE process and/or information modelling should read these executive summaries first.
+
+
+
The UML diagrams (in Chapter 5) offer a rapid way to see the main elements of the specifications and their relationships. The definition of the spatial object types, attributes, and relationships are included in the Feature Catalogue (also in Chapter 5). People having thematic expertise but not familiar with UML can fully understand the content of the data model focusing on the Feature Catalogue. Users might also find the Feature Catalogue especially useful to check if it contains the data necessary for the applications that they run. The technical details are expected to be of prime interest to those organisations that are responsible for implementing INSPIRE within the field of Area Management/Restriction/Regulation Zones and Reporting Units, but also to other stakeholders and users of the spatial data infrastructure.
+
+
+
The technical provisions and the underlying concepts are often illustrated by examples. Smaller examples are within the text of the specification, while longer explanatory examples and descriptions of selected use cases are attached in the annexes.
+
+
+
In order to distinguish the INSPIRE spatial data themes from the spatial object types, the INSPIRE spatial data themes are written in italics.
+
+
+
+
+
+
+
+
The document will be publicly available as a 'non-paper'. It does not represent an official position of the European Commission, and as such cannot be invoked in the context of legal procedures.
+
+
+
+
+
Legal Notice
+
+
+
Neither the European Commission nor any person acting on behalf of the Commission is responsible for the use which might be made of this publication.
+
+
+
Interoperability of Spatial Data Sets and Services – General Executive Summary
+
+
The challenges regarding the lack of availability, quality, organisation, accessibility, and sharing of spatial information are common to a large number of policies and activities and are experienced across the various levels of public authority in Europe. In order to solve these problems it is necessary to take measures of coordination between the users and providers of spatial information. The Directive 2007/2/EC of the European Parliament and of the Council adopted on 14 March 2007 aims at establishing an Infrastructure for Spatial Information in the European Community (INSPIRE) for environmental policies, or policies and activities that have an impact on the environment.
+
+
+
INSPIRE is based on the infrastructures for spatial information that are created and maintained by the Member States. To support the establishment of a European infrastructure, Implementing Rules addressing the following components of the infrastructure have been specified: metadata, interoperability of spatial data sets (as described in Annexes I, II, III of the Directive) and spatial data services, network services, data and service sharing, and monitoring and reporting procedures.
+
+
+
INSPIRE does not require collection of new data. However, after the period specified in the Directive[2] Member States have to make their data available according to the Implementing Rules.
+
+
+
Interoperability in INSPIRE means the possibility to combine spatial data and services from different sources across the European Community in a consistent way without involving specific efforts of humans or machines. It is important to note that "interoperability" is understood as providing access to spatial data sets through network services, typically via Internet. Interoperability may be achieved by either changing (harmonising) and storing existing data sets or transforming them via services for publication in the INSPIRE infrastructure. It is expected that users will spend less time and efforts on understanding and integrating data when they build their applications based on data delivered in accordance with INSPIRE.
+
+
+
In order to benefit from the endeavours of international standardisation bodies and organisations established under international law their standards and technical means have been utilised and referenced, whenever possible.
+
+
+
To facilitate the implementation of INSPIRE, it is important that all stakeholders have the opportunity to participate in specification and development. For this reason, the Commission has put in place a consensus building process involving data users, and providers together with representatives of industry, research and government. These stakeholders, organised through Spatial Data Interest Communities (SDIC) and Legally Mandated Organisations (LMO)[3], have provided reference materials, participated in the user requirement and technical[4] surveys, proposed experts for the Data Specification Drafting Team[5], the Thematic Working Groups[6] and other ad-hoc cross-thematic technical groups and participated in the public stakeholder consultations on draft versions of the data specifications. These consultations covered expert reviews as well as feasibility and fitness-for-purpose testing of the data specifications[7].
+
+
+
This open and participatory approach was successfully used during the development of the data specifications on Annex I, II and III data themes as well as during the preparation of the Implementing Rule on Interoperability of Spatial Data Sets and Services[8] for Annex I spatial data themes and of its amendment regarding the themes of Annex II and III.
+
+
+
The development framework elaborated by the Data Specification Drafting Team aims at keeping the data specifications of the different themes coherent. It summarises the methodology to be used for the development of the data specifications, providing a coherent set of requirements and recommendations to achieve interoperability. The pillars of the framework are the following technical documents[9]:
+
+
+
+
+
The Definition of Annex Themes and Scope 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 Model 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, some common code lists, etc. Those requirements of the Generic Conceptual Model that are directly implementable are included in the Implementing Rule on Interoperability of Spatial Data Sets and Services.
+
+
+
The Methodology for the Development of Data Specifications 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 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 Common data models are a set of documents that specify data models that are referenced by a number of different data specifications. These documents include generic data models for networks, coverages and activity complexes.
+
+
+
+
+
The structure of the data specifications is based on the "ISO 19131 Geographic information - Data product specifications" standard. They include the technical documentation of the application schema, the spatial object types with their properties, and other specifics of the spatial data themes using natural language as well as a formal conceptual schema language[10].
+
+
+
A consolidated model repository, feature concept dictionary, and glossary are being maintained to support the consistent specification development and potential further reuse of specification elements. The consolidated model consists of the harmonised models of the relevant standards from the ISO 19100 series, the INSPIRE Generic Conceptual Model, and the application schemas[11] developed for each spatial data theme. The multilingual INSPIRE Feature Concept Dictionary contains the definition and description of the INSPIRE themes together with the definition of the spatial object types present in the specification. The INSPIRE Glossary defines all the terms (beyond the spatial object types) necessary for understanding the INSPIRE documentation including the terminology of other components (metadata, network services, data sharing, and monitoring).
+
+
+
By listing a number of requirements and making the necessary recommendations, the data specifications enable full system interoperability across the Member States, within the scope of the application areas targeted by the Directive. The data specifications (in their version 3.0) are published as technical guidelines and provide the basis for the content of the Implementing Rule on Interoperability of Spatial Data Sets and Services[12]. The content of the Implementing Rule is extracted from the data specifications, considering short- and medium-term feasibility as well as cost-benefit considerations. The requirements included in the Implementing Rule are legally binding for the Member States according to the timeline specified in the INSPIRE Directive.
+
+
+
In addition to providing a basis for the interoperability of spatial data in INSPIRE, the data specification development framework and the thematic data specifications can be reused in other environments at local, regional, national and global level contributing to improvements in the coherence and interoperability of data in spatial data infrastructures.
+
+
+
Area Management/Restriction/Regulation Zones and Reporting Units – Executive Summary
+
+
The definition of the INSPIRE spatial data theme Area Management/Restriction/Regulation Zones and Reporting Units (AM theme) reflects the heterogeneous nature of the domains and topics that could be covered by this INSPIRE spatial data theme. The theme is defined generically in the INSPIRE Directive as "areas managed, regulated or used for reporting at international, European, national, regional and local levels". The AM data specification Technical Guidelines specify a wide range of zone types that are established or used for four different and sometimes overlapping concepts: manage, restrict, regulate and report.
+
+
+
The AM Guidelines reflect two basic concepts:
+
+
+
+
+
the need for spatial information on areas where specific management, restriction or regulative regimes are established, and
+
+
+
+
+
+
+
the definition of the "reporting units" within the scope of INSPIRE and the AM theme.
+
+
+
+
+
There are few limits to the scope of the theme. Area Management, Restriction and Regulation Zones are zones established in accordance with specific legislative requirements to deliver specific environmental objectives related to any environmental domain, for example, air, water, soil, biota (plants and animals), natural resources, land and land use. This includes, but is not limited to, objectives established to:
+
+
+
+
+
Protect and improve environmental quality (includes reducing pollution levels)
+
+
+
Protect and conserve environmental and natural resources
+
+
+
Protect and control risk from natural and man-made hazards
+
+
+
Protect plant, animal and human health
+
+
+
Control development and spatial planning
+
+
+
+
+
To achieve these objectives, a competent authority is commonly defined that is responsible for delivering, regulating and monitoring specific environmental objectives that may be defined within management or action plans.
+
+
+
Due to the broad scope of the theme, the modelling approach undertaken to develop the AM theme has been to define a generic core model that encompasses the management, restriction and regulation concepts using a predefined set of zone types which can be further extended by additional specialised zone types. This generic model can be used to exchange spatial data between different domains and public authorities. It is expected that this generic core model shall be extended (i.e. specialised) to define spatial objects that contain additional domain-specific properties. However, this detailed and domain-specific information is out of the scope of the AM theme.
+
+
+
Reporting units are based on legally defined environmental reporting obligations. Diverse spatial objects, defined within different INSPIRE spatial data themes, are used for providing a spatial reference for the data being reported under these reporting obligations, and these spatial objects can therefore be considered as reporting units. Therefore, no specific Reporting Units application schema is included in this data specification. Instead, the obligation on how to make reporting units spatial data available under INSPIRE is expressed in specific requirements. Annex G provides more information on reporting units within INSPIRE spatial data themes, including the AM theme.
+
+
+
The AM theme provides information on how to distinguish between the AM theme and other INSPIRE spatial data themes where close interrelationships exist between them. The resolutions to those interrelationships are provided on the basis of:
+
+
+
+
+
similarities of the scopes (e.g. INSPIRE themes Protected sites and Land use);
+
+
+
conceptual interrelationships (e.g. with Environmental Monitoring Facilities, Hydrography, Geology, Natural Risk Zones, Soil); or
+
+
+
sharing of the same geometry as another INSPIRE spatial object (e.g. Sea Regions, Geology, Administrative Units, Natural Risk Zones).
+
+
+
+
+
This AM Guidelines includes use cases which were used as the basis in the specification development process and examples of how to provide data based on the Area Management, Restriction and Regulation Zones Application Schema and how to extend the generic application schema of the AM theme into more detailed application schemas for specific thematic domains.
+
+
+
Acknowledgements
+
+
Many individuals and organisations have contributed to the development of these Guidelines.
+
+
+
The Thematic Working Group Area Management/Restriction/Regulation Zones and Reporting Units (TWG-AM) included:
+
+
+
Darja Lihteneger (TWG Facilitator), Debbie Wilson (TWG Editor), Stein Runar Bergheim, Maciej Borsa, Alex Coley, Ali Gül, Rob Haarman, Roger Longhorn, Tom Guilbert, Tor Gunnar Øverli, Luca Viarengo, Ebubekir Yüksel and Michael Lutz (European Commission contact point).
+
+
+
Other contributors to the INSPIRE data specifications are the Drafting Team Data Specifications, the JRC Data Specifications Team and the INSPIRE stakeholders - Spatial Data Interested Communities (SDICs) and Legally Mandated Organisations (LMOs).
+
+
+
Contact information
+
+
+
Maria Vanda Nunes de Lima & Michael Lutz
+European Commission Joint Research Centre (JRC)
+Institute for Environment and Sustainability
+Unit H06: Digital Earth and Reference Data
+http://inspire.ec.europa.eu/index.cfm/pageid/2
This document specifies a harmonised data specification for the spatial data theme Area Management/Restriction/Regulation Zones and Reporting Units as defined in Annex III of the INSPIRE Directive.
+
+
+
This data specification provides the basis for the drafting of Implementing Rules according to Article 7 (1) of the INSPIRE Directive [Directive 2007/2/EC]. The entire data specification is published as implementation guidelines accompanying these Implementing Rules.
+
+
+
+
+
+
2. Overview
+
+
+
2.1. Name
+
+
INSPIRE data specification for the theme Area Management/Restriction/Regulation Zones and Reporting Units.
+
+
+
+
2.2. Informal description
+
+
Definition:
+
+
+
Areas managed, regulated or used for reporting at international, European, national, regional and local levels. Includes dumping sites, restricted areas around drinking water sources, nitrate-vulnerable zones, regulated fairways at sea or large inland waters, areas for the dumping of waste, noise restriction zones, prospecting and mining permit areas, river basin districts, relevant reporting units and coastal zone management areas. [Directive 2007/2/EC]
+
+
+
Description:
+
+
+
The AM theme is thematically broad and encompasses a wide range of zone types that are established or used for four different and sometimes overlapping concepts:
+
+
+
+
+
Manage: zones are established to plan, perform, monitor and control activities to achieve specific legally defined environmental objectives. Examples include: air quality management zones, river basin districts, coastal management zones.
+
+
NOTE Goals can be continuous, e.g. the maintenance of a certain environmental state.
+
+
+
+
+
+
+
+
Restrict: zones are established to prohibit or limit certain activities, to only be performed within specific bounds and/or time periods, in order to achieve a certain purpose/goal according to legally defined responsibilities or obligations. Examples include: noise restriction zones, animal health restriction zones.
+
+
+
+
+
+
+
Regulate: zones are established to monitor and control certain activities (to permit, promote, prohibit, or restrict) to achieve legally defined environmental objectives. A regulated activity may require that if the environmental status is degraded then particular actions must be enacted to restore good environmental status.
+
+
NOTE 1: In specific cases, a regulative regime may define a set of acceptable limit/threshold values to protect human health or the environment.
+
+
+
NOTE 2: The distinction between regulation and restriction is not always clear, since restriction of activities implies that they are regulated.
+
+
+
+
+
+
+
+
Report: to evaluate the effectiveness of environmental policies and publish data and information (i.e. spatial data, observations, statistics, indicators) that can be used to assess progress towards maintaining or improving good environmental status and achievement of policy objectives.
+
+
NOTE 1: Member States shall regularly provide data and information to a responsible authority such as the Commission (i.e. reporting) that can be analysed to assess the state of the environment.
+
+
+
NOTE 2: Reporting data and information can be published in near-real time (e.g. observations) or published on a regular schedule (e.g. annually, 3-year intervals), as defined in the relevant legislation. Reporting data and information is often made publicly available after delivery to the relevant authority.
+
+
+
+
+
+
2.2.1. Scope and concepts
+
+
The heterogeneity of the thematic domains and concepts mentioned in the AM theme definition raised several questions about how broad should be the scope of the theme to support the aim of the INSPIRE Directive:
+
+
+
"the infrastructure should assist policy-making in relation to policies and activities that may have a direct or indirect impact on the environment".
+
+
+
Three main issues were examined to help define the scope of the AM theme:
+
+
+
+
+
How broad should be the thematic areas? Thematic areas cover a wide range of socio-economic activities, policies related to sustainable development and policies related to environmental issues and protection.
+
+
+
Requirements for areas managed, regulated or used for reporting are very diverse at different levels of administration and legislation, i.e. international, European, national and sub-national (regional and local), which impacts on how the areas are defined or established. How to balance between the requirements to include all relevant INSPIRE thematic areas and the need for a deeper level of detail within individual thematic areas?
+
+
+
+
+
It was important that limits to the scope of the theme were identified, where possible, and that an approach for handling generic versus domain-specific requirements was achieved.
+
+
+
The definition of the INSPIRE spatial data theme "Area Management/Restriction/Regulation Zones and Reporting Units" (AM) reflects two basic concepts:
+
+
+
+
+
the need for spatial information on areas where specific management, regulative or restriction regimes are established, and
+
+
+
+
+
+
+
the role of spatial objects as reporting units.
+
+
+
+
+
+
2.2.2. Scope related to the Area Management, Restriction and Regulation Zones
+
+
There are few limits to the scope of the theme. Area Management, Restriction and Regulation Zones are zones that are established in accordance with specific legislative requirements to deliver specific environmental objectives related to any environmental media, for example, air, water, soil and biota (plants and animals). This includes, but is not limited to, objectives established to:
+
+
+
+
+
Protect and improve environmental quality (includes reducing pollution levels),
+
+
+
Protect and conserve environmental and natural resources,
+
+
+
Protect and control risk from natural and man-made hazards,
+
+
+
Protect plant, animal and human health,
+
+
+
Control development and spatial planning.
+
+
+
+
+
To achieve these objectives, a competent authority is commonly defined that is responsible for delivering, regulating and monitoring specific environmental objectives that may be defined within management or action plans. Within such plans or programmes, measures may be defined that require specific activities to be controlled (permit, promote, prohibit, or restrict). Such activities may be controlled over continuous time periods or only within specific schedules. For example, noise levels from an entertainment venue may not exceed acceptable threshold values between 23:00 and 08:00 Sunday to Thursday and between 12 midnight and 08:00 Friday and Saturday.
+
+
+
ManagementRestrictionOrRegulationZones are any zones that are established in accordance with a legislative requirement related to an environmental policy or a policy or activity that may have an impact on the environment at any level of administration (international, European, national and sub-national) shall be a.
+
+
+
If a zone has been established for management, restriction or regulation but is not underpinned by a legislative requirement, it can be encoded as a ManagementRestrictionOrRegulationZone but this is not required under the INSPIRE Implementing Rules.
+
+
+
The scope of the AM theme has been modelled to ensure it is extensible and can support types of area management, restriction and regulation zones that were not identified during the theme development phase. The identified zone types are defined in the code list ZoneTypeCode.
+
+
+
+
2.2.3. Modelling approach
+
+
Due to the broad scope of the theme, the modelling approach undertaken to develop the AM theme was to define a generic core model that encompasses the core properties required to define an area management, restriction and regulation zone and treat the concept of reporting units separately.
+
+
+
Management, restrictions and regulations are related to the areas where those obligations are performed and executed. A specific area can be at the same time a subject to various restrictions / regulations or management regimes which may define diverse activities within those areas. For example: the same physical areas can have restrictions, specific management actions, plus reporting requirements, such as "sand replenishment to repair beach erosion" – all mandated by different legislation or regulations at different levels - European, national and sub-national (regional and local) – and at different scales.
+
+
+
The boundaries of the areas do not necessarily apply to the natural borders of geographic or natural phenomena and they could be based on a decision by the responsible authorities. For example:
+
+
+
+
+
a set of local administrative units or their parts might comprise an agglomeration area,
+
+
+
restriction zones around the coast, lakes or rivers usually cover surrounding areas of those phenomena and are defined within the areas of responsible authorities (administrative units or other territorial organisational units), or
+
+
+
river basin districts correspond to country (national) boundaries despite the natural flow of rivers through many countries.
+
+
+
+
+
This generic model can be used to exchange spatial data between different domains and public authorities. It is expected that this generic core model shall be extended (i.e. specialised) to define spatial objects that contain additional domain-specific properties. This detailed and domain-specific information is out of the scope of the AM theme. More detailed information and examples demonstrating how it is possible to extend the generic model into more specific and detailed thematic models are presented in Annex D and Annex E.
+
+
+
+
2.2.4. Reporting Units
+
+
The AM theme title states that the theme shall include "Reporting Units" and the definition states that the scope of the theme is:
+
+
+
"Areas managed, regulated or used for reporting at international, European, national, regional and local levels."
+
+
+
Both the title name and definition were initially ambiguous and difficult to interpret how best to handle and model Reporting Units within the scope of the AM theme. After discussions, both within the theme and with other INSPIRE Thematic Working Group members, a definition of "Reporting Units" is here defined as:
+
+
+
"A 'Reporting Unit' is a spatial object that provides the spatial reference for any non-spatial data exchanged under environmental reporting obligations."
+
+
+
The reported non-spatial data must include a property that contains a reference to the spatial object. This is typically an identifier, code or name and is a join key between the spatial and non-spatial objects enabling the data to be combined. This allows the non-spatial data to be visualised as a map or enable spatial analysis.
+
+
+
Examples of INSPIRE Reporting Units: AM and HY
+
+
+
Table 1 is an example of some annually reported air quality exceedence data for Slovakia from 2006. This reported data contains a join key (Zone code) to the Air Quality Management Zone which is a type of AM ManagementRestrictionOrRegulationZone. When joined to the "Reporting Unit" - AM Zone, a new map is generated for visualising exceedence (Figure 1).
+
+
+
Table 1 – Exceedence of SO2 limit values in Slovakia reported to EEA in 2006
+
+
+
+
+
+
+
+
+
+
- Form 8a List of zones in relation to limit value exceedences for SO2
+
+
+
+
+
Zone code
+
LV for health (24hr mean)
+
+
+
>LV
+
<LV
+
+
+
SKBA01.1
+
+
y
+
+
+
SKBA02
+
+
y
+
+
+
SKBB01
+
+
y
+
+
+
SKKO01.1
+
+
y
+
+
+
SKKO02
+
+
y
+
+
+
SKNI01
+
+
y
+
+
+
SKPR01
+
+
y
+
+
+
SKTN01
+
+
y
+
+
+
SKTR01
+
+
y
+
+
+
SKZI01
+
+
y
+
+
+
+
+
+
+
+
+
+
Figure 1 – Map visualising exceedence of daily limit values of SO2 within Air Quality Management Zones in Europe
+
+
+
However, AM Zones are not the only type of "Reporting Unit". Other INSPIRE spatial objects perform the role of "Reporting Unit". For example, surface waters: rivers, lakes and canals from Annex I Hydrography – Physical Waters are "Reporting Units" for indicators of chemical and ecological status (Figure 2).
+
+
+
Annex F contains a summary of identified examples where INSPIRE spatial objects act as Reporting Units for data reported under key European environmental legislation.
+
+
+
Thus, reporting units cannot be modelled as a distinct spatial object type. Therefore, no specific reporting units application schema is included in this data specification. Instead, the obligation on how to make reporting units spatial data available under INSPIRE is expressed in the following requirements.
+
+
+
+
+
+
📕
+
+
+
+
IR Requirement
+Annex IV, Section 11.4.2
+Theme-specific Requirements – Reporting Units
+
+
+
+
+
Spatial objects acting as reporting units shall be defined and made available according to the requirements of their respective INSPIRE spatial data theme(s).
+
+
+
Where environmental reporting data, to establish a spatial reference, refers to real-world entities that are made available as spatial objects in accordance with this Regulation, the reporting data shall include an explicit reference to those spatial objects.
+
+
+
+
+
+
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 1
+
+
+
Where an INSPIRE spatial object performs the role of "Reporting Unit", it is strongly recommended that it has an inspireId so that reporting data can be referenced to the spatial object.
+
+
+
+
+
+
+
+
+
+
+
+
Figure 2 – Map visualising ecological status or potential for rivers, canals and surface waters (2009)
+
+
+
+
2.2.5. Extending the AM Data Specification
+
+
Due to the broad scope of the theme, a generic modelling approach undertaken. A generic Area Management, Restriction and Regulation Zone spatial object was defined which can be classified using the zone type and specialised zone type properties.
+
+
+
NOTE The zone type and specialised zone type code list classification values are extensible allowing thematic communities and Member States to propose additional zone types that were not identified during the development phase of the AM data specification.
+
+
+
This generic spatial object defines a core set of properties that apply to any zone. This generic model can be used to exchange spatial data between different domains and public authorities. It is expected that this generic core model shall be extended (i.e. specialised) to define spatial objects that contain additional domain-specific properties (Figure 3).
+
+
+
+
+
+
+
+
Figure 3 – Extending INSPIRE AM Application Schema to generate Thematic application schemas
+
+
+
Detailed information and examples demonstrating how to extend the generic AM application schema into thematic data specification models are presented in:
+
+
+
+
+
Annex D: Water Framework Directive (WFD): Water Bodies
+
+
+
Annex E: Air Quality Directive (AQD) draft e-Reporting specification
+
+
+
+
+
Annex E: Water Framework Directive - Water Bodies
+
+
+
The Water Framework Directive: The Water Bodies application schema is included in the Technical Guideliens (TG), as it was defined as a candidate application schema during the development of the Annex I Hydrography theme. This candidate application schema was initially included in the Implementing Rule. However, it is proposed that this should only be a TG Requirement to allow Public Authorities to provide WFD Water Bodies within INSPIRE. It is envisaged that this example application schema shall either be formally adopted by WFD or amended when the WFD reporting data specification is updated in the future.
+
+
+
NOTE Minor changes were made to the candidate application schema to better integrate the proposed spatial object types with the ManagementRestrictionOrRegulationZone spatial object types and their relationships with spatial object types within the Hydrography theme and Geology theme, responsible for defining GroundwaterBodies.
+
+
+
Annex F: Air Quality Directive (AQD) draft e-Reporting specification
+
+
+
The AQD draft e-Reporting data specification has been included as an example to demonstrate how develop new reporting data specification by extending the INSPIRE applications. This draft data specification was developed by the EEA to meet the requirements of the Commission Implementing Decision 2011/850/EU defining the rules for the reciprocal exchange of information and reporting on ambient air quality for Directives 2004/107/EC and 2008/50/EC (see http://aqportal.eionet.europa.eu/).
+
+
+
+
2.2.6. Interrelationships with INSPIRE spatial data themes
+
+
2.2.6.1. Overlapping scope between Area Management, Restriction and Regulation Zones and other INSPIRE Themes
+
+
There is an overlap in scope between Area Management, Restriction and Regulation Zones (AM) and the following themes:
+
+
+
+
+
Annex I: Protected Sites (PS)
+
+
+
Annex III: Land Use (LU) – Planned Land Use application schema
+
+
+
+
+
Overlapping scope between AM and PS
+
+
+
The key difference between the two themes is that Protected Sites are established to manage, regulate and restrict activities to conserve nature, biodiversity and cultural heritage, only. Some Area Management, Restriction and Regulation Zones are established to deliver multiple environmental objectives that include nature and biodiversity conservation (e.g. River Basin Districts). Where this occurs, the spatial objects should only be published once, as Area Management, Restriction and Regulation Zones.
+
+
+
+
+
+
📕
+
+
+
+
IR Requirement
+Annex IV, Section 11.4.3
+Cross-theme requirements
+
+
+
+
+
If an area has been established exclusively to manage, regulate and restrict activities to conserve nature, biodiversity and cultural heritage, it shall be made available as a ProtectedSite spatial object. If a zone has been established to deliver multiple objectives, including the conservation of nature, biodiversity and cultural heritage, it shall be made available as a ManagementRestrictionOrRegulationZone spatial object.
+
+
+
+
+
+
+
+
+
Overlapping scope between AM and LU
+
+
+
To control development on land and marine environments, regulation zones are established. These define specific controls to regulate particular activities such as construction of buildings above a specified height or specific type within an area. Where such zones are defined within a legally binding spatial plan they fall within scope of the Land Use theme and should be defined using the Supplementary Regulation spatial object type within the Planned Land Use application schema.
+
+
+
If zones are established, but are not defined within a legally binding spatial plan, they should be defined as a Management Area, Restriction and Regulation Zone.
+
+
+
+
+
+
📕
+
+
+
+
IR Requirement
+Annex IV, Section 11.4.3
+Cross-theme requirements
+
+
+
+
+
Where a zone has been established to regulate planned land use and defined within a legally binding spatial plan, it falls within the scope of the Land Use theme and shall be made available as a SupplementaryRegulation. However, if the zone has been established by legislative requirement but not defined within a legally binding spatial plan, then it shall be made available as a ManagementRestrictionOrRegulationZone.
+
+
+
+
+
+
+
+
+
+
2.2.6.2. Interrelationships between Area Management, Restriction and Regulation Zones and other INSPIRE Themes
+
+
Because of the heterogeneity of domains covered by the AM theme, several interrelationships with other INSPIRE spatial data themes exist. The types of interrelationships include:
+
+
+
+
+
Associations or relationships between spatial objects
+
+
+
+
+
For example, associations have been defined between spatial object types within the following themes to represent explicit relationships between the themes.
+
+
+
+
+
Environmental Monitoring Facilities: MonitoringFacilities are established to monitor and assess the state of the environment within ManagementRestrictionOrRegulationZones
+
+
+
Hydrography: WFDSurfaceWaterBody are related to one or more HydroObject
+
+
+
Geology: WFD GroundWaterBody are related to one or more GroundWaterBody and/or HydrogeologicalUnit
+
+
+
Natural Risk Zone: a RiskZoneVector is contained within zero or more ManagementRestrictionOrRegulationZone
+
+
+
Soils: a ContaminatedSoilSite is contained within a ManagementRestrictionOrRegulationZone
+
+
+
+
+
+
+
Management, Restriction or Regulation Zone shares the same geometry as another INSPIRE spatial object
+
+
+
+
+
Zones are often defined based on the extent of another related spatial object.
+
+
+
+
+
Sea Regions: Marine Regions may derive their spatial extent fromas Sea Regions.
+
+
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 2
+
+
+
When the marine region has been established for the purpose of management or as restriction or regulation zone such spatial objects shall be defined as ManagementRestrictionOrRegulationZone of the INSPIRE AM theme. When the geometry of the marine regions that fall within the scope of the INSPIRE AM theme is derived or based on the geometry of the spatial objects defined in INSPIRE SR theme, both geometries shall be aligned at least at the land-sea boundaries following the related specifications in the INSPIRE SR theme.
+
+
+
+
+
+
+
+
+
Geology: Groundwater WFD Water Bodies may derive their extent from GE Groundwater Bodies.
+
+
+
Administrative Units: Air quality management zones may derive their spatial extend from Administrative Units or NUTS Regions.
+
+
+
Natural Risk Zones: Nitrate Vulnerable Zones or Flood Management Units may derive their spatial extent from RiskZone.
+
+
+
+
+
+
+
+
+
+
+
Definition:
+
+
+
Areas managed, regulated or used for reporting at international, European, national, regional and local levels. Includes dumping sites, restricted areas around drinking water sources, nitrate-vulnerable zones, regulated fairways at sea or large inland waters, areas for the dumping of waste, noise restriction zones, prospecting and mining permit areas, river basin districts, relevant reporting units and coastal zone management areas. [Directive 2007/2/EC]
+
+
+
Description:
+
+
+
The theme "Area Management/Restriction/Regulation Zones and Reporting Units" is thematically broad and encompasses any zones that are established in accordance with a legislative requirement related to an environmental policy or a policy or activity that may have an impact on the environment at any level of administration (international, European, national and sub-national).
+
+
+
The zones are typically established to deliver specific objectives related to any environmental media, for example, air, water, soil and biota (plants and animals). This includes, but is not limited to, objectives established to protect and improve environmental quality (includes reducing pollution levels), protect and conserve environmental and natural resources, protect and control risk from natural and man-made hazards, protect plant, animal and human health or control development.
+
+
+
The theme also addresses reporting units, which are defined as "spatial objects that provide the spatial reference for any non-spatial data exchanged under environmental reporting obligations." The reported non-spatial data must include a property that contains a reference to the spatial object. This is typically an identifier, code or name and is a join key between the spatial and non-spatial objects enabling the data to be combined. This allows the non-spatial data to be visualised as a map or enable spatial analysis.
+
+
+
Different INSPIRE spatial object types can perform the role of "Reporting Unit". For example, surface waters (rivers, lakes and canals from the Annex I theme Hydrography) are "Reporting Units" for indicators of chemical and ecological status. Thus, Reporting units cannot be modelled as a distinct spatial object type and no specific reporting units data model is defined. Instead, the theme defines obligations on how to make reporting units spatial data available under INSPIRE.
[Directive 91/271/EEC] Council Directive 91/271/EEC of 21 May 1991 concerning urban waste-water treatment
+
+
+
[Directive1991/676/EEC] Council Directive 91/676/EEC of 12 December 1991 concerning the protection of waters against pollution caused by nitrates from agricultural sources
+
+
+
[Directive 2000/60/EC] Directive 2000/60/EC of the European Parliament and of the Council of 23 October 2000 establishing a framework for Community action in the field of water policy
+
+
+
[Directive 2002/49/EC] 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 - Declaration by the Commission in the Conciliation Committee on the Directive relating to the assessment and management of environmental noise
+
+
+
[Directive 2006/44/EC] Directive 2006/44/EC of the European Parliament and of the Council of 6 September 2006 on the quality of fresh waters needing protection or improvement in order to support fish life
+
+
+
[Directive 2006/113/EC] Directive 2006/113/EC of the European Parliament and of the Council of 12 December 2006 on the quality required of shellfish waters [Directive 2008/50/EC] 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
+
+
+
[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)
+
+
+
[Directive 2007/60/EC] Directive 2007/60/EC of the European Parliament and of the Council of 23 October 2007 on the assessment and management of flood risks
+
+
+
[Directive 2008/56/EC] Directive 2008/56/EC of the European Parliament and of the Council of 17 June 2008 establishing a framework for community action in the field of marine environmental policy
+
+
+
[Directive 2008/98/EC] Directive 2008/98/EC of the European Parliament and of the Council of 19 November 2008 on waste and repealing certain Directives
+
+
+
[ISO 19105] EN ISO 19105:2000, Geographic information — Conformance and testing
+
+
+
[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 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-103r4] Implementation Specification for Geographic Information - Simple feature access – Part 1: Common Architecture v1.2.1
+
+
+
NOTE This is an updated version of "EN ISO 19125-1:2004, Geographic information – Simple feature access – Part 1: Common architecture".
+
+
+
[Regulation 1205/2008/EC] Regulation 1205/2008/EC implementing Directive 2007/2/EC of the European Parliament and of the Council as regards metadata
+
+
+
[Regulation 976/2009/EC] Commission Regulation (EC) No 976/2009 of 19 October 2009 implementing Directive 2007/2/EC of the European Parliament and of the Council as regards the Network Services
+
+
+
[Regulation 1089/2010/EC] Commission Regulation (EU) No 1089/2010 of 23 November 2010 implementing Directive 2007/2/EC of the European Parliament and of the Council as regards interoperability of spatial data sets and services
+
+
+
+
2.4. Terms and definitions
+
+
General terms and definitions helpful for understanding the INSPIRE data specification documents are defined in the INSPIRE Glossary[13].
+
+
+
Specifically, for the theme Area Management/Restriction/Regulation Zones and Reporting Units, the following terms are defined:
+
+
+
(1) manage
+
+
+
Plan, perform, monitor and control activities to achieve specific legally defined environmental objectives.
+
+
+
(2) restrict
+
+
+
Prohibit or limit certain activities, to only be performed within specific bounds and/or time periods, in order to achieve a certain purpose according to legally defined responsibilities or obligations.
+
+
+
(3) regulate
+
+
+
Monitor and control certain activities (to permit, promote, prohibit, or restrict) to achieve legally defined environmental objectives. A regulated activity may require that if the environmental status is degraded then particular actions must be enacted to restore good environmental status.
+
+
+
NOTE 1: In specific cases, a regulative regime may define a set of acceptable limit/threshold values to protect human health or the environment.
+
+
+
NOTE 2: The distinction between regulation and restriction is not always clear, since restriction of activities implies that they are regulated.
+
+
+
(4) report
+
+
+
Evaluate the effectiveness of environmental policies and publish data and information (i.e. spatial data, observations, statistics, indicators) that can be used to assess progress towards maintaining or improving good environmental status and achievement of policy objectives.
+
+
+
NOTE 1: Member States shall regularly provide data and information to a responsible authority such as the Commission (i.e. reporting) that can be analysed to assess the state of the environment.
+
+
+
NOTE 2: Reporting data and information can be published in near-real time (e.g. observations) or published on a regular schedule (e.g. annually, 3 year intervals), as defined in the relevant legislative instrument. Reporting data and information is often made publicly available after delivery to the relevant authority.
+
+
+
(5) reporting unit
+
+
+
Spatial object that provides the spatial reference for any non-spatial data exchanged under environmental reporting obligations.
+
+
+
(6) legal instrument
+
+
+
A document that specifies legal obligations, including, but not limited to, international conventions, laws and legal acts or implementing regulations at any administrative level.
+
+
+
(7) integrated coastal zone management
+
+
+
Integrated coastal zone management is a dynamic process for the sustainable management and use of coastal zones, taking into account at the same time the fragility of coastal ecosystems and landscapes, the diversity of activities and uses, their interactions, the maritime orientation of certain activities and uses and their impact on both the marine and land parts.
+
+
+
SOURCE: Protocol on Integrated Coastal Zone Management in the Mediterranean - signed in Madrid on 20-21 January 2008.
+
+
+
(8) climate
+
+
+
The statistical description in terms of the mean and variability of relevant quantities over a period of time ranging from months to thousands or millions of years. These quantities are most often surface variables such as temperature, precipitation, and wind.
NOTE 1 The classical period is 30 years, as defined by the World Meteorological Organization (WMO).
+
+
+
+
2.5. Symbols and abbreviations
+
+
+
+
+
+
+
+
AM
+
Area Management/Restriction/Regulation Zones and Reporting Units
+
+
+
AQD
+
Air Quality Directive (2008/50/EC)
+
+
+
ATS
+
Abstract Test Suite
+
+
+
CZM
+
Coastal Zone Management
+
+
+
EC
+
European Commission
+
+
+
EEA
+
European Environmental Agency
+
+
+
ETRS89
+
European Terrestrial Reference System 1989
+
+
+
ETRS89-LAEA
+
Lambert Azimuthal Equal Area
+
+
+
EVRS
+
European Vertical Reference System
+
+
+
FD
+
Floods Directive (2007/60/EC)
+
+
+
GCM
+
General Conceptual Model
+
+
+
GML
+
Geography Markup Language
+
+
+
IR
+
Implementing Rule
+
+
+
ISDSS
+
Interoperability of Spatial Data Sets and Services
+
+
+
ISO
+
International Organization for Standardization
+
+
+
ITRS
+
International Terrestrial Reference System
+
+
+
LAT
+
Lowest Astronomical Tide
+
+
+
LMO
+
Legally Mandated Organisation
+
+
+
LU
+
Land Use
+
+
+
MSFD
+
Marine Strategy Framework Directive (2008/56/EC)
+
+
+
PS
+
Protected Sites
+
+
+
RBD
+
River Basin District
+
+
+
SAC
+
Special Area of Conservation
+
+
+
SPA
+
Special Protection Area
+
+
+
SDIC
+
Spatial Data Interest Community
+
+
+
TG
+
Technical Guidance
+
+
+
UML
+
Unified Modeling Language
+
+
+
UTC
+
Coordinated Universal Time
+
+
+
TG
+
Technical Guidelines
+
+
+
TWG
+
Thematic Working Group
+
+
+
WFD
+
Water Framework Directive (2000/60/EC)
+
+
+
XML
+
EXtensible Markup Language
+
+
+
+
+
+
2.6. XML EXtensible Markup Language How the Technical Guidelines map to the Implementing Rules
+
+
The schematic diagram in Figure 4 gives an overview of the relationships between the INSPIRE legal acts (the INSPIRE Directive and Implementing Rules) and the INSPIRE Technical Guidelines. The INSPIRE Directive and Implementing Rules include legally binding requirements that describe, usually on an abstract level, what Member States must implement.
+
+
+
In contrast, the Technical Guidelines define how Member States might implement the requirements included in the INSPIRE Implementing Rules. As such, they may include non-binding technical requirements that must be satisfied if a Member State data provider chooses to conform to the Technical Guidelines. Implementing these Technical Guidelines will maximise the interoperability of INSPIRE spatial data sets.
+
+
+
+
+
+
+
+
Figure 4 - Relationship between INSPIRE Implementing Rules and Technical Guidelines
+
+
+
2.6.1. Requirements
+
+
The purpose of these Technical Guidelines (Data specifications on Area Management/Restriction/Regulation Zones and Reporting Units) is to provide practical guidance for implementation that is guided by, and satisfies, the (legally binding) requirements included for the spatial data theme Area Management/Restriction/Regulation Zones and Reporting Units in the Regulation (Implementing Rules) on interoperability of spatial data sets and services. These requirements are highlighted in this document as follows:
This style is used for requirements contained in the Implementing Rules on interoperability of spatial data sets and services (Commission Regulation (EU) No 1089/2010).
+
+
+
+
+
+
+
For each of these IR requirements, these Technical Guidelines contain additional explanations and examples.
+
+
+
NOTE The Abstract Test Suite (ATS) in Annex A contains conformance tests that directly check conformance with these IR requirements.
+
+
+
Furthermore, these Technical Guidelines may propose a specific technical implementation for satisfying an IR requirement. In such cases, these Technical Guidelines may contain additional technical requirements that need to be met in order to be conformant with the corresponding IR requirement when using this proposed implementation. These technical requirements are highlighted as follows:
+
+
+
+
+
+
📒
+
+
+
+
TG Requirement X
+
+
+
This style is used for requirements for a specific technical solution proposed in these Technical Guidelines for an IR requirement.
+
+
+
+
+
+
+
NOTE 1 Conformance of a data set with the TG requirement(s) included in the ATS implies conformance with the corresponding IR requirement(s).
+
+
+
NOTE 2 In addition to the requirements included in the Implementing Rules on interoperability of spatial data sets and services, the INSPIRE Directive includes further legally binding obligations that put additional requirements on data providers. For example, Art. 10(2) requires that Member States shall, where appropriate, decide by mutual consent on the depiction and position of geographical features whose location spans the frontier between two or more Member States. General guidance for how to meet these obligations is provided in the INSPIRE framework documents.
+
+
+
+
2.6.2. Recommendations
+
+
In addition to IR and TG requirements, these Technical Guidelines may also include a number of recommendations for facilitating implementation or for further and coherent development of an interoperable infrastructure.
+
+
+
+
+
+
📘
+
+
+
+
Recommendation X
+
+
+
Recommendations are shown using this style.
+
+
+
+
+
+
+
NOTE The implementation of recommendations is not mandatory. Compliance with these Technical Guidelines or the legal obligation does not depend on the fulfilment of the recommendations.
+
+
+
+
2.6.3. Conformance
+
+
Annex A includes the abstract test suite for checking conformance with the requirements included in these Technical Guidelines and the corresponding parts of the Implementing Rules (Commission Regulation (EU) No 1089/2010).
+
+
+
+
+
+
+
+
3. Specification scopes
+
+
+
This data specification does not distinguish different specification scopes, but just considers one general scope.
+
+
+
NOTE For more information on specification scopes, see [ISO 19131:2007], clause 8 and Annex D.
+
+
+
+
+
+
4. Identification information
+
+
+
These Technical Guidelines are identified by the following URI:
NOTE ISO 19131 suggests further identification information to be included in this section, e.g. the title, abstract or spatial representation type. The proposed items are already described in the document metadata, executive summary, overview description (section 2) and descriptions of the application schemas (section 5). In order to avoid redundancy, they are not repeated here.
+
+
+
+
+
+
5. Data content and structure
+
+
+
5.1. Application schemas – Overview
+
+
5.1.1. Application schemas included in the IRs
+
+
Articles 3, 4 and 5 of the Implementing Rules lay down the requirements for the content and structure of the data sets related to the INSPIRE Annex themes.
+
+
+
+
+
+
📕
+
+
+
+
IR Requirement
+Article 4
+Types for the Exchange and Classification of Spatial Objects
+
+
+
+
+
For the exchange and classification of spatial objects from data sets meeting the conditions laid down in Article 4 of Directive 2007/2/EC, Member States shall use the spatial object types and associated data types and code lists that are defined in Annexes II, III and IV for the themes the data sets relate to.
+
+
+
When exchanging spatial objects, Member States shall comply with the definitions and constraints set out in the Annexes and provide values for all attributes and association roles set out for the relevant spatial object types and data types in the Annexes. For voidable attributes and association roles for which no value exists, Member States may omit the value.
+
+
+
+
+
+
+
+
+
The types to be used for the exchange and classification of spatial objects from data sets related to the spatial data theme Area Management/Restriction/Regulation Zones and Reporting Units are defined in the following application schemas (see section 5.3):
+
+
+
+
+
AreaManagementRestrictionAndRegulationZones
+
+
+
+
+
The application schemas specify requirements on the properties of each spatial object including its multiplicity, domain of valid values, constraints, etc.
+
+
+
NOTE The application schemas presented in this section contain some additional information that is not included in the Implementing Rules, in particular multiplicities of attributes and association roles.
+
+
+
+
+
+
📒
+
+
+
+
TG Requirement 1
+
+
+
Spatial object types and data types shall comply with the multiplicities defined for the attributes and association roles in this section.
+
+
+
+
+
+
+
An application schema may include references (e.g. in attributes or inheritance relationships) to common types or types defined in other spatial data themes. These types can be found in a sub-section called "Imported Types" at the end of each application schema section. The common types referred to from application schemas included in the IRs are addressed in Article 3.
+
+
+
+
+
+
📕
+
+
+
+
IR Requirement
+Article 3
+Common Types
+
+
+
Types that are common to several of the themes listed in Annexes I, II and III to Directive 2007/2/EC shall conform to the definitions and constraints and include the attributes and association roles set out in Annex I.
+
+
+
+
+
+
+
NOTE Since the IRs contain the types for all INSPIRE spatial data themes in one document, Article 3 does not explicitly refer to types defined in other spatial data themes, but only to types defined in external data models.
+
+
+
Common types are described in detail in the Generic Conceptual Model [DS-D2.7], in the relevant international standards (e.g. of the ISO 19100 series) or in the documents on the common INSPIRE models [DS-D2.10.x]. For detailed descriptions of types defined in other spatial data themes, see the corresponding Data Specification TG document [DS-D2.8.x].
+
+
+
+
5.1.2. Additional recommended application schemas
+
+
In addition to the application schemas listed above, the following additional application schemas have been defined for the theme Area Management/Restriction/Regulation Zones and Reporting Units:
+
+
+
+
+
ControlledActivities (see section 5.4)
+
+
+
WaterFrameworkDirective (see Annex E)
+
+
+
+
+
These additional application schemas are not included in the IRs. They typically address requirements from specific (groups of) use cases and/or may be used to provide additional information. They are included in this specification in order to improve interoperability also for these additional aspects and to illustrate the extensibility of the application schemas included in the IRs.
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 1
+
+
+
Additional and/or use case-specific information related to the theme Area Management/Restriction/Regulation Zones and Reporting Units should be made available using the spatial object types and data types specified in the following application schema(s): ControlledActivities, WaterFrameworkDirective.
+
+
+
These spatial object types and data types should comply with the definitions and constraints and include the attributes and association roles defined in this section.
+
+
+
The code lists used in attributes or association roles of spatial object types or data types should comply with the definitions and include the values defined in this section.
+
+
+
+
+
+
+
+
+
5.2. Basic notions
+
+
This section explains some of the basic notions used in the INSPIRE application schemas. These explanations are based on the GCM [DS-D2.5].
+
+
+
5.2.1. Notation
+
+
5.2.1.1. Unified Modeling Language (UML)
+
+
The application schemas included in this section are specified in UML, version 2.1. The spatial object types, their properties and associated types are shown in UML class diagrams.
+
+
+
NOTE For an overview of the UML notation, see Annex D in [ISO 19103].
+
+
+
The use of a common conceptual schema language (i.e. UML) allows for an automated processing of application schemas and the encoding, querying and updating of data based on the application schema – across different themes and different levels of detail.
+
+
+
The following important rules related to class inheritance and abstract classes are included in the IRs.
+
+
+
+
+
+
📕
+
+
+
+
IR Requirement
+Article 5
+Types
+
+
+
(…)
+
+
+
+
+
Types that are a sub-type of another type shall also include all this type’s attributes and association roles.
+
+
+
Abstract types shall not be instantiated.
+
+
+
+
+
+
+
+
+
The use of UML conforms to ISO 19109 8.3 and ISO/TS 19103 with the exception that UML 2.1 instead of ISO/IEC 19501 is being used. The use of UML also conforms to ISO 19136 E.2.1.1.1-E.2.1.1.4.
+
+
+
NOTE ISO/TS 19103 and ISO 19109 specify a profile of UML to be used in conjunction with the ISO 19100 series. This includes in particular a list of stereotypes and basic types to be used in application schemas. ISO 19136 specifies a more restricted UML profile that allows for a direct encoding in XML Schema for data transfer purposes.
+
+
+
To model constraints on the spatial object types and their properties, in particular to express data/data set consistency rules, OCL (Object Constraint Language) is used as described in ISO/TS 19103, whenever possible. In addition, all constraints are described in the feature catalogue in English, too.
+
+
+
NOTE Since "void" is not a concept supported by OCL, OCL constraints cannot include expressions to test whether a value is a void value. Such constraints may only be expressed in natural language.
+
+
+
+
5.2.1.2. Stereotypes
+
+
In the application schemas in this section several stereotypes are used that have been defined as part of a UML profile for use in INSPIRE [DS-D2.5]. These are explained in Table 2 below.
+
+
+
Table 2 – Stereotypes (adapted from [DS-D2.5])
+
+
+
+
+
+
+
+
+
+
Stereotype
+
Model element
+
Description
+
+
+
applicationSchema
+
Package
+
An INSPIRE application schema according to ISO 19109 and the Generic Conceptual Model.
+
+
+
leaf
+
Package
+
A package that is not an application schema and contains no packages.
+
+
+
featureType
+
Class
+
A spatial object type.
+
+
+
type
+
Class
+
A type that is not directly instantiable, but is used as an abstract collection of operation, attribute and relation signatures. This stereotype should usually not be used in INSPIRE application schemas as these are on a different conceptual level than classifiers with this stereotype.
+
+
+
dataType
+
Class
+
A structured data type without identity.
+
+
+
union
+
Class
+
A structured data type without identity where exactly one of the properties of the type is present in any instance.
+
+
+
codeList
+
Class
+
A code list.
+
+
+
import
+
Dependency
+
The model elements of the supplier package are imported.
+
+
+
voidable
+
Attribute, association role
+
A voidable attribute or association role (see section 5.2.2).
+
+
+
lifeCycleInfo
+
Attribute, association role
+
If in an application schema a property is considered to be part of the life-cycle information of a spatial object type, the property shall receive this stereotype.
+
+
+
version
+
Association role
+
If in an application schema an association role ends at a spatial object type, this stereotype denotes that the value of the property is meant to be a specific version of the spatial object, not the spatial object in general.
+
+
+
+
+
+
+
5.2.2. Voidable characteristics
+
+
The «voidable» stereotype is used to characterise those properties of a spatial object that may not be present in some spatial data sets, even though they may be present or applicable in the real world. This does not mean that it is optional to provide a value for those properties.
+
+
+
For all properties defined for a spatial object, a value has to be provided – either the corresponding value (if available in the data set maintained by the data provider) or the value of void. A void value shall imply that no corresponding value is contained in the source spatial data set maintained by the data provider or no corresponding value can be derived from existing values at reasonable costs.
+
+
+
+
+
+
📘
+
+
+
+
Recommendation 2
+
+
+
The reason for a void value should be provided where possible using a listed value from the VoidReasonValue code list to indicate the reason for the missing value.
+
+
+
+
+
+
+
The VoidReasonValue type is a code list, which includes the following pre-defined values:
+
+
+
+
+
Unpopulated: The property is not part of the dataset maintained by the data provider. However, the characteristic may exist in the real world. For example when the "elevation of the water body above the sea level" has not been included in a dataset containing lake spatial objects, then the reason for a void value of this property would be 'Unpopulated'. The property receives this value for all spatial objects in the spatial data set.
+
+
+
Unknown: The correct value for the specific spatial object is not known to, and not computable by the data provider. However, a correct value may exist. For example when the "elevation of the water body above the sea level" of a certain lake has not been measured, then the reason for a void value of this property would be 'Unknown'. This value is applied only to those spatial objects where the property in question is not known.
+
+
+
Withheld: The characteristic may exist, but is confidential and not divulged by the data provider.
+
+
+
+
+
NOTE It is possible that additional reasons will be identified in the future, in particular to support reasons / special values in coverage ranges.
+
+
+
The «voidable» stereotype does not give any information on whether or not a characteristic exists in the real world. This is expressed using the multiplicity:
+
+
+
+
+
If a characteristic may or may not exist in the real world, its minimum cardinality shall be defined as 0. For example, if an Address may or may not have a house number, the multiplicity of the corresponding property shall be 0..1.
+
+
+
If at least one value for a certain characteristic exists in the real world, the minimum cardinality shall be defined as 1. For example, if an Administrative Unit always has at least one name, the multiplicity of the corresponding property shall be 1..*.
+
+
+
+
+
In both cases, the «voidable» stereotype can be applied. In cases where the minimum multiplicity is 0, the absence of a value indicates that it is known that no value exists, whereas a value of void indicates that it is not known whether a value exists or not.
+
+
+
EXAMPLE If an address does not have a house number, the corresponding Address object should not have any value for the «voidable» attribute house number. If the house number is simply not known or not populated in the data set, the Address object should receive a value of void (with the corresponding void reason) for the house number attribute.
+
+
+
+
5.2.3. Code lists
+
+
Code lists are modelled as classes in the application schemas. Their values, however, are managed outside of the application schema.
+
+
+
5.2.3.1. Code list types
+
+
The IRs distinguish the following types of code lists.
+
+
+
+
+
+
📕
+
+
+
+
IR Requirement
+Article 6
+Code Lists for Spatial Data Sets
+
+
+
+
+
The code lists included in this Regulation set out the multilingual thesauri to be used for the key attributes, in accordance with Article 8(2), point (c), of Directive 2007/2/EC.
+
+
+
The Commission shall establish and operate an INSPIRE code list register at Union level for managing and making publicly available the values that are included in the code lists referred to in paragraph 1.
+
+
+
The Commission shall be assisted by the INSPIRE Commission expert group in the maintenance and update of the code list values.
+
+
+
Code lists shall be one of the following types:
+
+
+
+
code lists whose values comprise only the values specified in the INSPIRE code list register;
+
+
+
code lists whose values comprise the values specified in the INSPIRE code list register and narrower values defined by data providers;
+
+
+
code lists whose values comprise the values specified in the INSPIRE code list register and additional values at any level defined by data providers;
+
+
+
code lists, whose values comprise any values defined by data providers.
+
+
+
+
+
+
Code lists may be hierarchical. Values of hierarchical code lists may have a more general parent value.
+
+
+
Where, for an attribute whose type is a code list as referred to in paragraph 4, points (b), (c) or (d), a data provider provides a value that is not specified in the INSPIRE code list register, that value and its definition and label shall be made available in another register.
+
+
+
+
+
+
+
+
+
The type of code list is represented in the UML model through the tagged value extensibility, which can take the following values:
+
+
+
+
+
none, representing code lists whose allowed values comprise only the values specified in the IRs (type a);
+
+
+
narrower, representing code lists whose allowed values comprise the values specified in the IRs and narrower values defined by data providers (type b);
+
+
+
open, representing code lists whose allowed values comprise the values specified in the IRs and additional values at any level defined by data providers (type c); and
+
+
+
any, representing code lists, for which the IRs do not specify any allowed values, i.e. whose allowed values comprise any values defined by data providers (type d).
+
+
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 3
+
+
+
Additional values defined by data providers should not replace or redefine any value already specified in the IRs.
+
+
+
+
+
+
+
NOTE This data specification may specify recommended values for some of the code lists of type (b), (c) and (d) (see section 5.2.4.3). These recommended values are specified in a dedicated Annex.
+
+
+
In addition, code lists can be hierarchical, as explained in Article 6(5) of the IRs.
+
+
+
+
+
+
📕
+
+
+
+
IR Requirement
+Article 6
+Code Lists for Spatial Data Sets
+
+
+
(…)
+
+
+
+
+
Code lists may be hierarchical. Values of hierarchical code lists may have a more general parent value
+
+
+
+
+
+
+
+
+
The type of code list and whether it is hierarchical or not is also indicated in the feature catalogues.
+
+
+
+
5.2.3.2. Obligations on data providers
+
+
+
+
+
📕
+
+
+
+
IR Requirement
+Article 6
+Code Lists for Spatial Data Sets
+
+
+
(….)
+
+
+
+
+
Where, for an attribute whose type is a code list as referred to in paragraph 4, points (b), (c) or (d), a data provider provides a value that is not specified in the INSPIRE code list register, that value and its definition and label shall be made available in another register.
+
+
+
+
+
+
+
+
+
Article 6(6) obliges data providers to use only values that are allowed according to the specification of the code list. The "allowed values according to the specification of the code list" are the values explicitly defined in the IRs plus (in the case of code lists of type (b), (c) and (d)) additional values defined by data providers.
+
+
+
For attributes whose type is a code list of type (b), (c) or (d) data providers may use additional values that are not defined in the IRs. Article 6(6) requires that such additional values and their definition be made available in a register. This enables users of the data to look up the meaning of the additional values used in a data set, and also facilitates the re-use of additional values by other data providers (potentially across Member States).
+
+
+
NOTE Guidelines for setting up registers for additional values and how to register additional values in these registers is still an open discussion point between Member States and the Commission.
+
+
+
+
5.2.3.3. Recommended code list values
+
+
For code lists of type (b), (c) and (d), this data specification may propose additional values as a recommendation (in a dedicated Annex). These values will be included in the INSPIRE code list register. This will facilitate and encourage the usage of the recommended values by data providers since the obligation to make additional values defined by data providers available in a register (see section 5.2.4.2) is already met.
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 4
+
+
+
Where these Technical Guidelines recommend values for a code list in addition to those specified in the IRs, these values should be used.
+
+
+
+
+
+
+
NOTE For some code lists of type (d), no values may be specified in these Technical Guidelines. In these cases, any additional value defined by data providers may be used.
+
+
+
+
5.2.3.4. Governance
+
+
The following two types of code lists are distinguished in INSPIRE:
+
+
+
+
+
Code lists that are governed by INSPIRE (INSPIRE-governed code lists). These code lists will be managed centrally in the INSPIRE code list register. Change requests to these code lists (e.g. to add, deprecate or supersede values) are processed and decided upon using the INSPIRE code list register’s maintenance workflows.
+
+
INSPIRE-governed code lists will be made available in the INSPIRE code list register at http://inspire.ec.europa.eu/codelist/<CodeListName>. They will be available in SKOS/RDF, XML and HTML. The maintenance will follow the procedures defined in ISO 19135. This means that the only allowed changes to a code list are the addition, deprecation or supersession of values, i.e. no value will ever be deleted, but only receive different statuses (valid, deprecated, superseded). Identifiers for values of INSPIRE-governed code lists are constructed using the pattern http://inspire.ec.europa.eu/codelist/<CodeListName>/<value>.
+
+
+
+
Code lists that are governed by an organisation outside of INSPIRE (externally governed code lists). These code lists are managed by an organisation outside of INSPIRE, e.g. the World Meteorological Organization (WMO) or the World Health Organization (WHO). Change requests to these code lists follow the maintenance workflows defined by the maintaining organisations. Note that in some cases, no such workflows may be formally defined.
+
+
Since the updates of externally governed code lists is outside the control of INSPIRE, the IRs and these Technical Guidelines reference a specific version for such code lists.
+
+
+
The tables describing externally governed code lists in this section contain the following columns:
+
+
+
+
+
The Governance column describes the external organisation that is responsible for maintaining the code list.
+
+
+
The Source column specifies a citation for the authoritative source for the values of the code list. For code lists, whose values are mandated in the IRs, this citation should include the version of the code list used in INSPIRE. The version can be specified using a version number or the publication date. For code list values recommended in these Technical Guidelines, the citation may refer to the "latest available version".
+
+
+
In some cases, for INSPIRE only a subset of an externally governed code list is relevant. The subset is specified using the Subset column.
+
+
+
The Availability column specifies from where (e.g. URL) the values of the externally governed code list are available, and in which formats. Formats can include machine-readable (e.g. SKOS/RDF, XML) or human-readable (e.g. HTML, PDF) ones.
+
+
+
+
+
Code list values are encoded using http URIs and labels. Rules for generating these URIs and labels are specified in a separate table.
+
+
+
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 5
+
+
+
The http URIs and labels used for encoding code list values should be taken from the INSPIRE code list registry for INSPIRE-governed code lists and generated according to the relevant rules specified for externally governed code lists.
+
+
+
+
+
+
+
NOTE Where practicable, the INSPIRE code list register could also provide http URIs and labels for externally governed code lists.
+
+
+
+
5.2.3.5. Vocabulary
+
+
For each code list, a tagged value called "vocabulary" is specified to define a URI identifying the values of the code list. For INSPIRE-governed code lists and externally governed code lists that do not have a persistent identifier, the URI is constructed following the pattern http://inspire.ec.europa.eu/codelist/<UpperCamelCaseName>;.
+
+
+
If the value is missing or empty, this indicates an empty code list. If no sub-classes are defined for this empty code list, this means that any code list may be used that meets the given definition.
+
+
+
An empty code list may also be used as a super-class for a number of specific code lists whose values may be used to specify the attribute value. If the sub-classes specified in the model represent all valid extensions to the empty code list, the subtyping relationship is qualified with the standard UML constraint "\{complete,disjoint}".
+
+
+
+
+
5.2.4. Identifier management
+
+
+
+
+
📕
+
+
+
+
IR Requirement
+Article 9
+Identifier Management
+
+
+
+
+
The data type Identifier defined in Section 2.1 of Annex I shall be used as a type for the external object identifier of a spatial object.
+
+
+
The external object identifier for the unique identification of spatial objects shall not be changed during the life-cycle of a spatial object.
+
+
+
+
+
+
+
+
+
NOTE 1 An external object identifier is a unique object identifier which is published by the responsible body, which may be used by external applications to reference the spatial object. [DS-D2.5]
+
+
+
NOTE 2 Article 9(1) is implemented in each application schema by including the attribute inspireId of type Identifier.
+
+
+
NOTE 3 Article 9(2) is ensured if the namespace and localId attributes of the Identifier remains the same for different versions of a spatial object; the version attribute can of course change.
+
+
+
+
5.2.5. Geometry representation
+
+
+
+
+
📕
+
+
+
+
IR Requirement
+Article 12
+Other Requirements & Rules
+
+
+
+
+
The value domain of spatial properties defined in this Regulation shall be restricted to the Simple Feature spatial schema as defined in Herring, John R. (ed.), OpenGIS® Implementation Standard for Geographic information – Simple feature access – Part 1: Common architecture, version 1.2.1, Open Geospatial Consortium, 2011, unless specified otherwise for a specific spatial data theme or type.
+
+
+
+
+
+
+
+
+
NOTE 1 The specification restricts the spatial schema to 0-, 1-, 2-, and 2.5-dimensional geometries where all curve interpolations are linear and surface interpolations are performed by triangles.
+
+
+
NOTE 2 The topological relations of two spatial objects based on their specific geometry and topology properties can in principle be investigated by invoking the operations of the types defined in ISO 19107 (or the methods specified in EN ISO 19125-1).
+
+
+
+
5.2.6. Temporality representation
+
+
The application schema(s) use(s) the derived attributes "beginLifespanVersion" and "endLifespanVersion" to record the lifespan of a spatial object.
+
+
+
The attributes "beginLifespanVersion" specifies the date and time at which this version of the spatial object was inserted or changed in the spatial data set. The attribute "endLifespanVersion" specifies the date and time at which this version of the spatial object was superseded or retired in the spatial data set.
+
+
+
NOTE 1 The attributes specify the beginning of the lifespan of the version in the spatial data set itself, which is different from the temporal characteristics of the real-world phenomenon described by the spatial object. This lifespan information, if available, supports mainly two requirements: First, knowledge about the spatial data set content at a specific time; second, knowledge about changes to a data set in a specific time frame. The lifespan information should be as detailed as in the data set (i.e., if the lifespan information in the data set includes seconds, the seconds should be represented in data published in INSPIRE) and include time zone information.
+
+
+
NOTE 2 Changes to the attribute "endLifespanVersion" does not trigger a change in the attribute "beginLifespanVersion".
+
+
+
+
+
+
📕
+
+
+
+
IR Requirement
+Article 10
+Life-cycle of Spatial Objects
+
+
+
(…)
+
+
+
+
+
Where the attributes beginLifespanVersion and endLifespanVersion are used, the value of endLifespanVersion shall not be before the value of beginLifespanVersion.
+
+
+
+
+
+
+
+
+
NOTE The requirement expressed in the IR Requirement above will be included as constraints in the UML data models of all themes.
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 6
+
+
+
If life-cycle information is not maintained as part of the spatial data set, all spatial objects belonging to this data set should provide a void value with a reason of "unpopulated".
+
+
+
+
+
+
+
5.2.6.1. Validity of the real-world phenomena
+
+
The application schema(s) use(s) the attributes "validFrom" and "validTo" to record the validity of the real-world phenomenon represented by a spatial object.
+
+
+
The attributes "validFrom" specifies the date and time at which the real-world phenomenon became valid in the real world. The attribute "validTo" specifies the date and time at which the real-world phenomenon is no longer valid in the real world.
+
+
+
Specific application schemas may give examples what "being valid" means for a specific real-world phenomenon represented by a spatial object.
+
+
+
+
+
+
📕
+
+
+
+
IR Requirement
+Article 12
+Other Requirements & Rules
+
+
+
(…)
+
+
+
+
+
Where the attributes validFrom and validTo are used, the value of validTo shall not be before the value of validFrom.
+
+
+
+
+
+
+
+
+
NOTE The requirement expressed in the IR Requirement above will be included as constraints in the UML data models of all themes.
+
+
+
+
+
+
5.3. Application schema Area Management Restriction and Regulation Zones
+
+
5.3.1. Description
+
+
5.3.1.1. Narrative description
+
+
The Area Management, Restriction and Regulation Zones Application Schema contains the core model for defining zones established in accordance with specific legislative requirements to manage, restrict or regulate activities to protect the environment. A single spatial object type "ManagementRestrictionOrRegulationZone" has been defined to represent the zone as the concepts of management, restriction and regulation overlap and many zones are established to perform at least two of the three concepts.
+
+
+
The ManagementRestrictionOrRegulationZone spatial object type contains a core set of properties that are common to all types of zone. These can be categorised into 3 sets of properties:
+
+
+
+
+
Zone specific properties: these are properties that provide a basic set of information describing the zone:
+
+
+
+
geometry: The geometry representing the spatial extent of the spatial object. Typically the geometry of a zone shall be represented as either a surface or multi-surface. However, there may be zone that are represented as either point or a line.
+
+
+
designationPeriod: Time period defining when the management, restriction or regulation zone was legally designated or became effective in the real world.
+
+
+
competentAuthority: description of the organisation(s) responsible managing, restricting or regulating measures or activities within the zone.
+
+
+
legalBasis: reference to, or citation of the legislative instrument or document that required the establishment of a zone.
+
+
NOTE 1 LegislationCitation is defined in section 9.8.3 of D2.5 Generic Conceptual Model v3.4.
+
+
+
NOTE 2 For each ManagementRestrictionOrRegulationZone, at least the most specific legal instrument that required the establishment of zone shall be provided.
+
+
+
+
+
+
📘
+
+
+
+
Recommendation 7
+
+
+
If applicable, the relevant legal basis at European level should also be provided.
+
+
+
+
+
+
+
+
plan: reference to, or citation of a plan (management or action plan) that describes the environmental objectives and measures that shall be undertaken in the zone to protect the environment.
+
+
+
relatedZone: reference to one or more related ManagementRestrictionOrRegulationZones. The related zone may either be a sub zone or a zone of different type.
+
+
+
+
+
+
Classification and selection properties: due to the generic nature of the model additional properties were required to enable different types of zone to be distinguished. These are defined using two classification properties:
+
+
+
+
zoneType: which provide a high level classification of the zone. This is often a generalised classification for all types of zone for a specific thematic area (e.g. animalHealthRestrictionZone). This shall be an extensible INSPIRE code list (see section 5.3.1.2).
+
+
+
specialisedZoneType: this allows more specific classification of the zone. This shall be a relevant zone type defined from an externally governed domain or community code list, where available. If no code list exists then this shall be the commonly used name assigned to the zone within the domain or community (preferably in English).
+
+
+
environmentalDomain: this has been included to enable users to retrieve multiple types of zone that exist within a domain as it was recognised that some users may not know what zone types exist.
+
+
+
+
+
+
Identification and maintenance properties:
+
+
+
+
inspireId: object references have been defined from other INSPIRE Annex themes to the ManagementRestrictionOrRegulationZone. An inspireId is an external object identifier published by the responsible data provider with the intention that they may be used by third parties for referencing. Also as zones are typically "Reporting Units", they also require external object identifiers to enable them to be referenced by non-spatial reported data. See section 14.1 of D2.5 for more details about how to encode external object identifiers.
+
+
+
thematicID: thematic object identifier are additional identifiers that have been assigned to the zone. Multiple thematic object identifiers may be assigned to a zone where different data exchange requirements (e.g. national vs European reporting) have defined different lexical rules for thematic object identifiers. Where multiple thematic object identifiers exist all should be provided. This shall allows external datasets that use these thematic object identifiers for referencing to link to the INSPIRE spatial object.
+
+
+
name: name used to identify the management, regulation or restriction zone in the real world.
+
+
+
beginLifespanVersion: date and time at which this version of the spatial object was inserted or changed in the spatial data set.
+
+
+
endLifespanVersion: date and time at which this version of the spatial object was superseded or retired in the spatial data set.
+
+
+
+
+
+
+
+
The INSPIRE-defined code lists included in this application schema include the values specified in the tables in this section.
+
+
+
+
5.3.1.2. Code lists
+
+
Two INSPIRE-governed code lists have been defined within the Area Management Restriction and Regulation Zones application schema:
+
+
+
+
+
ZoneTypeCode
+
+
+
Environmental Domain
+
+
+
+
+
ZoneTypeCode
+
+
+
The ZoneTypeCode code list shall be an extensible INSPIRE-governed code list. This code list defines a high level classification for types of ManagementRestrictionOrRegulationZones. At the time of the development of the data specification an initial list of ZoneTypeCodes has been defined that set the initial scope of the theme. However, it is recognised that this code list does not cover all high-level types of zone type in all domains. Consequently this code list shall be extensible using any code list value defined by Member States and thematic communities.
+
+
+
To extend this code list, Member States and thematic communities should only define a set of code lists that define new high-level zone types. If the proposed zone type falls within the scope of an exisiting ZoneTypeCode then the proposed zone type code should be used as a SpecialisedZoneTypeCode.
+
+
+
For example, if a thematic community wants to define the zone type code: Bluetongue Restriction Zone then this should not be an allowable ZoneTypeCode extension value as this is a specialised zone type code (i.e. narrower) for the INSPIRE zone type code: Animal Health Restriction Zone.
+
+
+
An allowable example of a thematic community or Member State zone type code extension would be: Land Use Restriction Zone.
+
+
+
The intention to allow the INSPIRE-governed ZoneTypeCode code list to be extensible is to enable Public Authorities the ability to publish any dataset they identify that falls within the scope of the AM theme. If a set of extended ZoneTypeCode values are commonly used then thematic communities and Member States should propose these values to be included in the INSPIRE ZoneTypeCode code list through the Data Specification Maintenance Process.
+
+
+
Environmental Domain
+
+
+
The Environmental Domain code list shall be non-extensible INSPIRE-governed. The Environmental Domain code list defines a set of environmental policy domains. It is expected that some ManagementRestrictionOrRegulationZones are cross cut several environmental policy domains. Where this occurs, each environmental domain should be defined.
+
+
+
Changes to the Environmental Domain code list shall be managed according the to Data Specification Maintenance Process.
+
+
+
+
5.3.1.3. UML Overview
+
+
+
+
+
+
+
Figure 5 – UML class diagram: Overview of the Area Management Restriction and Regulation Zones application schema
+
+
+
+
+
+
+
+
Figure 6 – UML package diagram: Overview of the Area Management Restriction and Regulation Zones application schema
+
+
+
+
+
+
+
+
Figure 7 – UML class diagram: Overview of the code lists contained within the Area Management Restriction and Regulation Zones application schema
+
+
+
+
5.3.1.4. Consistency between spatial data sets
+
+
5.3.1.4.1. Consistency between spatial data sets that share geometries
+
+
Some ManagementRestrictionOrRegulationZone spatial objects derive their geometry from another spatial object. Where this occurs the geometries of both spatial objects shall be consistent.
+
+
+
+
+
+
📕
+
+
+
+
IR Requirement
+Annex IV, Section 11.4.1
+Theme-specific Requirements – Management Restriction Or Regulation Zones
+
+
+
+
+
Where the geometry of the spatial object is derived from another spatial object, the geometries of the two objects shall be consistent.
+
+
+
+
+
+
+
+
+
NOTE Any inconsistencies can be detected using data matching algorithms.
+
+
+
+
+
5.3.1.5. Identifier management
+
+
ManagementRestrictionOrRegulationZone spatial objects shall be assigned an inspireId in accordance with the rules for Identifier Management defined in section 14 of D2.5 Generic Conceptual Model. The requirement for an inspireId follows Recommendation 27 from section 14 of D2.5:
+
+
+
+
+
+
+
+
From Section 14 of D2.5 Generic Conceptual Model
+
+
+
+
+
+
+
+
+
+
+
+
The inspireId is required for ManagementRestrictionOrRegulationZone spatial objects to enable references from non-spatial resources to be established. The inspireId shall be a persistent, external object identifier. This means that the inspireId shall provide a consistent identifier enabling multiple non-spatial resources to be linked to the same ManagementRestrictionOrRegulationZone.
+
+
+
The identifier assigned as the inspireId shall follow the four requirements for external object identifiers:
+
+
+
+
+
Uniqueness: the identifier shall not be assigned to any other INSPIRE spatial object.
+
+
NOTE 1: Different versions of the spatial object shall have the same identifier
+
+
+
NOTE 2: Identifiers must not be re-used
+
+
+
+
Persistence: once assigned the identifier shall remain unchanged during the life-time of a spatial object
+
+
+
Traceability: a spatial object (or specific version) can be accessed based on its identifier
+
+
+
Feasibility: the system for defining identifiers has been designed to allow existing identifiers to be used
+
+
+
+
+
The inspireId contains three properties: localID, namespace and a «voidable» version. Where an INSPIRE Download Service provides access to multiple versions of spatial objects, the version parameter should be included to enable third parties to include the version of the spatial object when the referencing.
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 8
+
+
+
It is strongly recommended that a version is included in the inspireId to allow different versions of a spatial object to be distinguished.
+
+
+
+
+
+
+
Relationship between inspireId and thematicId
+
+
+
Many ManagementRestrictionOrRegulationZone spatial objects have been assigned multiple identifiers based on different identifier schemes that have been defined for data exchange for specific requirements (e.g. national versus European reporting. Thematic identifiers have been and shall continue to be the key used to link non-spatial data to the ManagementRestrictionOrRegulationZone spatial object. To ensure that none of these identifiers and links are lost, a thematicId has been added to the ManagementRestrictionOrRegulationZone.
+
+
+
The key difference between the inspireId and thematicId is that the inspireId shall be a persistent, unique identifier that can be used in external datasets to reference to the spatial object by any third party. Whereas the thematicID is a descriptive unique object identifier assigned to the spatial object defined in an information community.
+
+
+
NOTE A thematic identifier may form part of the inspireId.
+
+
+
Some ManagementRestrictionOrRegulationZone spatial objects may be assigned more than one thematic identifier. These thematic identifiers may have been assigned to meet internal data maintenance requirements or are identification codes assigned at national, European or International level.
+
+
+
Example: River Basin Districts
+
+
+
The WISE River Basin Districts v1.4 data specification defines the following identifier properties that are assigned to a River Basin District:
+
+
+
+
+
+
+
+
+
Attribute Name
+
Description
+
+
+
+
+
Database Internal Key (Object ID)
+
Internal unique identifier (Primary Key).
+
+
+
EU RBD Code
+
Unique RBD code submitted by MS via WFD Art. 3 reporting, national RBD code. National code prefixed by country code.
+
+
+
MS RBD Code
+
Unique RBD code submitted by MS via WFD Art. 13 reporting, national RBD code.
+
+
+
International Code
+
RBD codes for non EU countries.
+
+
+
European RBD Code
+
A code assigned at EU level according to the international RBD the national RBD is part of.
+
+
+
+
+
NOTE The internal unique identifier should not published as it serves as an internal primary key and is therefore not suitable for use as either an inspireId or thematicID.
+
+
+
The four RBD code properties should be encoded as thematicIDs. A thematicID is encoded using the ThematicIdentifier class defined in the GCM (Base Types 2 package) (Figure 8).
+
+
+
+
+
+
+
+
Figure 8 - UML Class Diagram of ThematicIdentifier «dataType»
+
+
+
The ThematicIdentifier is comprised of two properties:
+
+
+
+
+
identifier: this is a descriptive unique object identifier assigned to the spatial object ((.g. AT2000, 2000 or AT5001 are different River Basin District codes assigned to Rhine)
+
+
+
identifierScheme: this is preferably a HTTP URI used to identify which scheme is was used to define the identifier. See D2.7 Guidelines for the encoding of spatial data for more information about defining URIs for identifierSchemes.
+
+
+
+
+
+
5.3.1.6. Modelling of object references
+
+
Object referencing does not apply to the geometries of ManagementRestrictionOrRegulationZone spatial objects.
+
+
+
Although the geometry of many ManagementRestrictionOrRegulationZone spatial objects are derived from other INSPIRE spatial objects, it was agreed during the development of the data specification that the benefits of sharing geometries are greatest for data maintenance rather than data exchange. Few services and applications currently do not adequately support object referencing. Therefore, the geometries of ManagementRestrictionOrRegulationZone spatial objects shall be explicitly defines using coordinates.
+
+
+
+
5.3.1.7. Geometry representation
+
+
Typically the representation of the geometry of a ManagementRestrictionOrRegulationZone shall be either a GM_Surface or GM_MultiSurface. However, it has been recognised that at some levels of detail the geometry may be represented as either a GM_Point or GM_Curve. Consequently, any constraints on the geometry representation have been removed.
+
+
+
The requirements to support different geometry representations has required that the geometry data type uses the Abstract GM_Object class, allowing any geometry to be used.
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 9
+
+
+
If a ManagementRestrictionOrRegulationZone should represent an area in the real world, then the geometry should be represented as either a GM_Surface or GM_MultiSurface.
+
+
+
+
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 10
+
+
+
Where a ManagementRestrictionOrRegulationZone is comprised of multiple parts (i.e. surfaces) only one instance of a ManagementRestrictionOrRegulationZone spatial object should be provided. The geometry should be represented as a GM_MultiSurface.
+
+
+
+
+
+
+
+
5.3.1.8. Temporality representation
+
+
The temporality of a ManagementRestrictionOrRegulationZone spatial object is represented by two types of properties:
+
+
+
+
+
Transactional lifecycle properties: beginLifespanVersion and endLifespanVersion
+
+
+
Real-world validity property: designationPeriod
+
+
+
+
+
The designationPeriod defines the time period (beginPosition and endPosition) when the ManagementRestrictionOrRegulationZone was legally designated or became effective in the real world.
+
+
+
The designationPeriod uses the TM_Period property from ISO 19108:2006. This provides greater encoding flexibility and improved semantics that defining separate "validTo" and "validFrom" that use xsd:DateTime.
+
+
+
TM_Period is implemented using the gml:TimePeriodType. It requires that both the beginPosition and endPosition are provided. If the ManagementRestrictionOrRegulationZone does not have a defined endPosition (i.e. it is unknown) then the endPosition/indeterminatePosition attribute should be used to state that the ManagementRestrictionOrRegulationZone is effective until an unknown endPosition.
+
+
+
The values that can be defined are flexible. The beginPosition and endPosition use the TM_Position type which is a union of ISO 8601 Date, Time or DateTime.
INSPIRE Application Schema Area Management Restriction and Regulation Zones
+
+
+
Version number
+
3.0
+
+
+
+
+
Types defined in the feature catalogue
+
+
+
+
+
+
+
+
+
+
Type
+
Package
+
Stereotypes
+
+
+
+
+
ManagementRestrictionOrRegulationZone
+
Area Management Restriction and Regulation Zones
+
«featureType»
+
+
+
+
+
5.3.2.1. Spatial object types
+
+
5.3.2.1.1. ManagementRestrictionOrRegulationZone
+
+
+
+
+
+
+
ManagementRestrictionOrRegulationZone
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
management restriction or regulation zone
+
+
+
Definition:
+
Area managed, restricted or regulated in accordance with a legal requirement related to an environmental policy or a policy or activity that may have an impact on the environment at any level of administration (or used for reporting at international, European, national, regional and local) levels.
+
+
+
Stereotypes:
+
«featureType»
+
+
+
+
+
+
+
Attribute: inspireId
+
+
+
+
+
+
+
+
+
Name:
+
inspireID
+
+
+
Value type:
+
Identifier
+
+
+
Definition:
+
External object identifier of the spatial object.
+
+
+
Description:
+
An external object identifier is a unique object identifier published by the responsible body, which may be used by external application to reference the spatial object. The identifier is an identifier of the spatial object, not an identifier of the real-world phenomenon.
+
+NOTE ManagementRestrictionOrRegulationZone spatial objects commonly perform the role/function of "Reporting Unit" for non-spatial reported data. The reported data shall contain object references to ManagementRestrictionOrRegulationZones. Therefore, all spatial objects shall be assigned an inspireID.
+
+
+
Multiplicity:
+
1
+
+
+
+
+
+
+
Attribute: thematicId
+
+
+
+
+
+
+
+
+
Name:
+
thematic identifier
+
+
+
Value type:
+
ThematicIdentifier
+
+
+
Definition:
+
Descriptive unique object identifier applied to spatial objects in a defined information theme.
+
+
+
Description:
+
Some management, restriction or regulation zones may be assigned multiple thematic identifiers. These may have been established to meet the reporting requirements of different legislative instruments at International, European or at Member State levels.
+
+Where multiple thematicIDs exist all should be provided. This shall allow any external dataset that uses thematicIDs to referencing to the zone to continue to be linked to the spatial object.
+
+
+
Multiplicity:
+
0..*
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: name
+
+
+
+
+
+
+
+
+
Name:
+
name
+
+
+
Value type:
+
GeographicalName
+
+
+
Definition:
+
A geographical name that is used to identify the management, restriction or regulation zone in the real world. It provides a 'key' for implicitly associating different representations of the object.
+
+
+
Multiplicity:
+
0..*
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: geometry
+
+
+
+
+
+
+
+
+
Name:
+
Name geometry
+
+
+
Value type:
+
GM_Object
+
+
+
Definition:
+
The geometry representing the spatial extent of the spatial object.
+
+
+
Description:
+
The geometry of a Management Area, Restriction or Regulation Zone can be defined using any geometry representation. Typically this shall be either a GM_Surface or GM_MultiSurface.
+
+NOTE Where a zone forms as a polygon, this should be encoded as a GM_Surface or GM_MultiSurface not a GM_Curve.
+
+
+
Multiplicity:
+
1
+
+
+
+
+
+
+
Attribute: zoneType
+
+
+
+
+
+
+
+
+
Name:
+
zone type
+
+
+
Value type:
+
ZoneTypeCode
+
+
+
Definition:
+
High level classification defining the type of management, restriction or regulation zone.
+
+
+
Multiplicity:
+
1..*
+
+
+
Values:
+
The allowed values for this code list comprise the values specified in the INSPIRE Registry and additional values at any level defined by data providers.
+
+
+
+
+
+
+
Attribute: specialisedZoneType
+
+
+
+
+
+
+
+
+
Name:
+
specialised zone type
+
+
+
Value type:
+
SpecialisedZoneTypeCode
+
+
+
Definition:
+
Additional classification value which further specialises the type of management, regulation or restriction zone relevant to the domain.
+
+
+
Description:
+
+
+
+
Multiplicity:
+
0..1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
Values:
+
The allowed values for this code list comprise any values defined by data providers.
+
+
+
+
+
+
+
Attribute: designationPeriod
+
+
+
+
+
+
+
+
+
Name:
+
designation period
+
+
+
Value type:
+
TM_Period
+
+
+
Definition:
+
Time period defining when the management, restriction or regulation zone was legally designated or became effective in the real world.
+
+
+
Description:
+
NOTE designationPeriod uses the ISO 19108 TM_Period which is comprised of two properties - gml:beginPosition and gml:endPosition.
+If the zone shall remain in force for an indeterminate period of time then the endPosition/indeterminatePosition="unknown" can be used to state that the zone is still effective.
+
+
+
Multiplicity:
+
1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: environmentalDomain
+
+
+
+
+
+
+
+
+
Name:
+
environmental domain
+
+
+
Value type:
+
EnvironmentalDomain
+
+
+
Definition:
+
Classification of the environment domain(s) for which, through the establishment of the zone, certain environmental objectives shall be reached.
+
+
+
Description:
+
A zone may be established within one environmental domain (e.g. water) or may to cover a wide range of environmental objectives that cross-cut several domains. For example, Marine Regions may relate to water, land use, sustainable development.
+
+
+
Multiplicity:
+
1..*
+
+
+
Values:
+
The allowed values for this code list comprise only the values specified in the INSPIRE Registry.
+
+
+
+
+
+
+
Attribute: competentAuthority
+
+
+
+
+
+
+
+
+
Name:
+
competent authority
+
+
+
Value type:
+
RelatedParty
+
+
+
Definition:
+
Description of the organisation(s) responsible for managing, restricting or regulating measures or activities within the zone.
+
+
+
Multiplicity:
+
1..*
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: beginLifespanVersion
+
+
+
+
+
+
+
+
+
Name:
+
begin lifespan version
+
+
+
Value type:
+
DateTime
+
+
+
Definition:
+
Date and time at which this version of the spatial object was inserted or changed in the spatial data set.
+
+
+
Multiplicity:
+
1
+
+
+
Stereotypes:
+
«voidable,lifeCycleInfo»
+
+
+
+
+
+
+
Attribute: endLifespanVersion
+
+
+
+
+
+
+
+
+
Name:
+
end lifespan version
+
+
+
Value type:
+
DateTime
+
+
+
Definition:
+
Date and time at which this version of the spatial object was superseded or retired in the spatial data set.
+
+
+
Multiplicity:
+
0..1
+
+
+
Stereotypes:
+
«voidable,lifeCycleInfo»
+
+
+
+
+
+
+
Association role: legalBasis
+
+
+
+
+
+
+
+
+
Value type:
+
LegislationCitation
+
+
+
Definition:
+
Reference to, or citation of the legal instrument or document that required the establishment of the zone.
+
+
+
Multiplicity:
+
1..*
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Association role: relatedZone
+
+
+
+
+
+
+
+
+
Value type:
+
ManagementRestrictionOrRegulationZone
+
+
+
Definition:
+
Reference to a related management, regulation or restriction zone.
+
+
+
Description:
+
EXAMPLE 1: River basin districts (RBD) exist at three levels:
+1) International River Basin District
+2) National River Basin District
+3) River Basin District Sub units.
+
+An international RBD may contain one or more national RBD and/or River Basin Sub Units.
+
+A national RBD may be related to an International RBD and one or more RBD sub-units.
+
+EXAMPLE 2: A WFDWaterBody may be related to a River Basin District.
+
+
+
Multiplicity:
+
0..*
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Association role: plan
+
+
+
+
+
+
+
+
+
Value type:
+
DocumentCitation
+
+
+
Definition:
+
Reference to, or citation of a plan (management or action plan) that describes the environmental objectives and measures that shall be undertaken in the zone to protect the environment.
+
+
+
Multiplicity:
+
0..*
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Constraint: competentAuthority.role shall be "authority"
+
+
+
+
+
+
+
+
+
Natural language:
+
The role attribute of the competentAuthority shall take the value "authority".
The allowed values for this code list comprise only the values specified in the INSPIRE Registry.
+
+
+
+
+
+
+
+
+
5.3.2.2.2. SpecialisedZoneTypeCode
+
+
+
+
+
+
+
SpecialisedZoneTypeCode
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
specialised zone type code
+
+
+
Definition:
+
Additional classification value that defines the specialised type of zone.
+
+
+
Description:
+
+
For some ManagementRestrictionOrRegulationZones each zone may be further specialised. This is used to indicate that additional controls (activities or measures)may be in force depending on its specialised type.
+Example 1: Air Quality Management Zones - can be specialised as either:
+* agglomerations
+* nonAgglomeration
+Example 2: Animal Health Restriction Zones - can be specialised as either:
+* restrictionZone
+* protectionZone
+* controlZone
+* lowerRiskZone
+* surveillanceZone
The allowed values for this code list comprise the values specified in the INSPIRE Registry and additional values at any level defined by data providers.
+
+
+
+
+
+
+
+
+
+
5.3.2.3. Imported types (informative)
+
+
This section lists definitions for feature types, data types and code lists that are defined in other application schemas. The section is purely informative and should help the reader understand the feature catalogue presented in the previous sections. For the normative documentation of these types, see the given references.
+
+
+
5.3.2.3.1. DateTime
+
+
+
+
+
+
+
DateTime
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
Date and Time
+
+
+
Reference:
+
Geographic information — Conceptual schema language [ISO/TS 19103:2005]
+
+
+
+
+
+
+
+
+
5.3.2.3.2. GM_Object
+
+
+
+
+
+
+
GM_Object (abstract)
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
Geometry root
+
+
+
Reference:
+
Geographic information — Spatial schema [ISO 19107:2003]
+
+
+
+
+
+
+
+
+
5.3.2.3.3. GeographicalName
+
+
+
+
+
+
+
GeographicalName
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
Geographical Names
+
+
+
Reference:
+
INSPIRE Data specification on Geographical Names [DS-D2.8.I.3]
+
+
+
Definition:
+
Proper noun applied to a real world entity.
+
+
+
+
+
+
+
+
+
5.3.2.3.4. Identifier
+
+
+
+
+
+
+
Identifier
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
Base Types
+
+
+
Reference:
+
INSPIRE Generic Conceptual Model, version 3.4 [DS-D2.5]
+
+
+
Definition:
+
External unique object identifier published by the responsible body, which may be used by external applications to reference the spatial object.
+
+
+
Description:
+
NOTE1 External object identifiers are distinct from thematic object identifiers.
+
+NOTE 2 The voidable version identifier attribute is not part of the unique identifier of a spatial object and may be used to distinguish two versions of the same spatial object.
+
+NOTE 3 The unique identifier will not change during the life-time of a spatial object.
+
+
+
+
+
+
+
+
+
5.3.2.3.5. RelatedParty
+
+
+
+
+
+
+
RelatedParty
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
Base Types 2
+
+
+
Reference:
+
INSPIRE Generic Conceptual Model, version 3.4 [DS-D2.5]
+
+
+
Definition:
+
An organisation or a person with a role related to a resource.
+
+
+
Description:
+
NOTE 1 A party, typically an individual person, acting as a general point of contact for a resource can be specified without providing any particular role.
+
+
+
+
+
+
+
+
+
5.3.2.3.6. TM_Period
+
+
+
+
+
+
+
TM_Period
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
Temporal Objects
+
+
+
Reference:
+
Geographic information — Temporal schema [ISO 19108:2002/Cor 1:2006]
+
+
+
+
+
+
+
+
+
5.3.2.3.7. ThematicIdentifier
+
+
+
+
+
+
+
ThematicIdentifier
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
Base Types 2
+
+
+
Reference:
+
INSPIRE Generic Conceptual Model, version 3.4 [DS-D2.5]
+
+
+
Definition:
+
Thematic identifier to uniquely identify the spatial object.
+
+
+
Description:
+
Some spatial objects may be assigned multiple unique identifiers.
+These may have been established to meet data exchange requirements of different reporting obligations at International, European or national levels and/or internal data maintenance requirements.
+
+
+
+
+
+
+
+
+
+
+
5.3.3. Externally governed code lists
+
+
Within the Area Management Restriction and Regulation Zone application schema, it is expected that the values that should be included in the SpecialisedZoneTypeCode are derived from externally governed code lists maintained by thematic communities or Member States.
+
+
+
To date, no such externally governed code lists have been identified. Several example SpecialisedZoneTypeCode code lists have been defined for the following ZoneTypeCodes:
+
+
+
+
+
Air Quality Management Zone
+
+
+
Noise Restriction Zone
+
+
+
Sensitive Area
+
+
+
Animal Health Restriction Zone
+
+
+
WFD Water Body
+
+
+
River Basin District
+
+
+
Designated Waters
+
+
+
Marine Region
+
+
+
+
+
Examples code list values are listed in Annex E.2.
+
+
+
+
+
5.4. Application schema Controlled Activities
+
+
5.4.1. Description
+
+
5.4.1.1. Narrative description
+
+
The controlled activities application schema is a TG Recommendation that should be used if a ManagementRestrictionOrRegulationZone contains specific activities that are controlled (permitted, prohibited, promoted or restricted) within the zone. These activities may be controlled for a specified time period.
+
+
+
Examples of controlled activities include:
+
+
+
+
+
Restricting specific development types within a spatial planning restriction zone (e.g. cannot construct building greater than a specified height)
+
+
+
Prohibiting animal and human movements during an disease outbreak (e.g. Foot and Mouth, Avian Influenza).
+
+
+
Permitting abstraction of natural resources (minerals/water)
+
+
+
Permitting the emission of pollutants
+
+
+
Restrict noise levels during specific times of day
+
+
+
Restrict hunting during specified times of the year
+
+
+
+
+
As the AM theme covers a broad range of domains it was not possible to define a definitive set of controlled activities that could be modelled within INSPIRE. Instead the aim has been to identify a high-level set of activity types to facilitate interoperability using the activity property in the ControlledActivity data type. The exact type of activity that is controlled within the zone can be specified using the specialisedActivityType and description properties.
+
+
+
Invariably, activities are controlled via prohibition, restriction or permission these controls apply for a specified time period. Therefore, a restrictionPeriod property has been defined using the Schedule data type.
+
+
+
The aim of the Schedule data type is to provide a generic, flexibility data type enabling the encoding of a range of different use cases for restricted periods. These include:
+
+
+
+
+
Define an individual day or set of days: Monday or Weekends or Public Holidays
+
+
+
Define a range of days: Monday to Thursday
+
+
+
Define a set of days: Monday, Tuesday, Thursday
+
+
+
Define a date or range of dates: 2010-10-01 or 2010-04-01 to 2010-04-30
+
+
+
Define a day/range or set of days and time period: Monday between 12:30-13:30, Monday to Thursday 9am to 5pm 2010-10-01 between 12:30 and 17:00
+
+
+
+
+
NOTE If only a day, set or a range of days/dates is defined then it is assumed that the restricted period applies for 24 hours.
+
+
+
As this extension only defines an additional property: controlledActivity, the requirements for: consistency between spatial objects, identifier management, modelling of object references and geometry and temporality representation defined for the ManagementRestrictionOrRegulationZone also apply here.
+
+
+
+
5.4.1.2. UML Overview
+
+
+
+
+
+
+
Figure 9 – UML class diagram: Overview of the Controlled Activities application schema
+
+
+
+
+
+
+
+
Figure 10 – UML package diagram: Overview of the Controlled Activities application schema
+
+
+
+
+
+
+
+
Figure 11 – UML class diagram: Overview of the code lists contained within the Controlled Activities application schema
+
+
+
+
+
5.4.2. Feature catalogue
+
+
Feature catalogue metadata
+
+
+
+
+
+
+
+
+
Application Schema
+
INSPIRE Application Schema Controlled Activities
+
+
+
Version number
+
3.0
+
+
+
+
+
Types defined in the feature catalogue
+
+
+
+
+
+
+
+
+
+
Type
+
Package
+
Stereotypes
+
+
+
ControlledActivityInformation
+
Controlled Activities
+
«dataType»
+
+
+
DayOrDate
+
Controlled Activities
+
«union»
+
+
+
ManagementRestrictionOrRegulationZone
+
Controlled Activities
+
«featureType»
+
+
+
Schedule
+
Controlled Activities
+
«dataType»
+
+
+
+
+
5.4.2.1. Spatial object types
+
+
5.4.2.1.1. ManagementRestrictionOrRegulationZone
+
+
+
+
+
+
+
ManagementRestrictionOrRegulationZone
+
+
+
+
+
+
+
+
+
+
+
+
Subtype of:
+
ManagementRestrictionOrRegulationZone
+
+
+
Definition:
+
Area managed, regulated or used for reporting at international, European, national, regional and local levels.
+
+
+
Description:
+
Extended to include information describing activities that are controlled to achieve specific environment objectives within the zone.
+
+
+
Stereotypes:
+
«featureType»
+
+
+
+
+
+
+
Attribute: controlledActivity
+
+
+
+
+
+
+
+
+
Value type:
+
ControlledActivityInformation
+
+
+
Definition:
+
A controlled activity is an activity that is either permitted, prohibited, promoted or restricted within the zone.
+
+
+
Description:
+
+
+
+
Multiplicity:
+
0..*
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
+
+
+
5.4.2.2. Data types
+
+
5.4.2.2.1. ControlledActivityInformation
+
+
+
+
+
+
+
ControlledActivityInformation
+
+
+
+
+
+
+
+
+
+
+
+
Definition:
+
Information describing the type of activity that is controlled within the zone.
+
+
+
Stereotypes:
+
«dataType»
+
+
+
+
+
+
+
Attribute: controlMeasure
+
+
+
+
+
+
+
+
+
Value type:
+
ControlTypeCode
+
+
+
Definition:
+
Type of control method used to manage activities or measures within the zone.
+
+
+
Description:
+
+
+
+
Multiplicity:
+
1
+
+
+
Values:
+
The allowed values for this code list comprise any values defined by data providers.
+
+
+
+
+
+
+
Attribute: activity
+
+
+
+
+
+
+
+
+
Value type:
+
ControlledActivityType
+
+
+
Definition:
+
Type of activity that is controlled within the zone.
+
+
+
Description:
+
This is an extensible INSPIRE codelist containing high-level classification of activity areas. The specific type of activity that this controlled should be defined using the specialisedActivity.
+
+
+
Multiplicity:
+
1..*
+
+
+
Values:
+
The allowed values for this code list comprise any values defined by data providers.
+
+
+
+
+
+
+
Attribute: specialisedActivity
+
+
+
+
+
+
+
+
+
Value type:
+
SpecialisedActivityTypeCode
+
+
+
Definition:
+
Specific activity type defining the activity that is controlled in the zone.
+
+
+
Description:
+
The specialisedActivity is a codelist value that should be derived from thematic or Member State codelist. The specialisedActivity should be an relevant activity that has a narrower definition than the ControlledActivityType.
+
+Example:
+
+If the ControlledActivityType is "plantAndAnimalHealth" the specialisedActivity could be "movement" or more specifically "animalMovement" and "humanMovement" (if human movements into an out of a restricted zone apply as was the case with Foot and Mouth disease outbreak in the UK).
+
+
+
Multiplicity:
+
0..*
+
+
+
Stereotypes:
+
«voidable»
+
+
+
Values:
+
The allowed values for this code list comprise any values defined by data providers. INSPIRE Registry includes recommended values that may be used by data providers.
+
+
+
+
+
+
+
Attribute: description
+
+
+
+
+
+
+
+
+
Value type:
+
CharacterString
+
+
+
Definition:
+
Narrative summary providing any additional information that explains what controls apply to the activity.
+
+
+
Multiplicity:
+
0..1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: restrictionPeriod
+
+
+
+
+
+
+
+
+
Value type:
+
Schedule
+
+
+
Definition:
+
Time period defining when restrictions apply.
+
+
+
Description:
+
NOTE Specific controls may apply to the activities or measures within specified time periods.
+
+There are several key use cases for defining a schedule for an activity such as a restriction:
+
+Define a day or set of days: Monday or Weekends or Public Holidays
+Define a range of days: Monday to Thursday
+Define a set of days: Monday, Tuesday, Thursday
+Define a date or range of dates: 2010-10-01 or 2010-04-01 to 2010-04-30
+Define a day/range or set of days and time period: Monday between 12:30-13:30, Monday to Thursday 9am to 5pm 2010-10-01 between 12:30 and 17:00
+
+
+
Multiplicity:
+
0..*
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
+
+
5.4.2.2.2. DayOrDate
+
+
+
+
+
+
+
DayOrDate
+
+
+
+
+
+
+
+
+
+
+
+
Definition:
+
Choice to specify either the day or start day on which a restriction applies if it is a reoccurring scheduled restriction or a specific date or start date on which a restriction applies.
+
+
+
Stereotypes:
+
«union»
+
+
+
+
+
+
+
Attribute: day
+
+
+
+
+
+
+
+
+
Value type:
+
DayTypeCode
+
+
+
Definition:
+
A specified day
+
+
+
Multiplicity:
+
1
+
+
+
Values:
+
The allowed values for this code list comprise any values defined by data providers.
+
+
+
+
+
+
+
Attribute: date
+
+
+
+
+
+
+
+
+
Value type:
+
Date
+
+
+
Definition:
+
A specified date
+
+
+
Multiplicity:
+
1
+
+
+
+
+
+
+
+
+
5.4.2.2.3. Schedule
+
+
+
+
+
+
+
Schedule
+
+
+
+
+
+
+
+
+
+
+
+
Definition:
+
Reoccurring time period defining when an activity is controlled.
+
+
+
Stereotypes:
+
«dataType»
+
+
+
+
+
+
+
Attribute: day
+
+
+
+
+
+
+
+
+
Value type:
+
DayOrDate
+
+
+
Definition:
+
Day on which the restriction starts or days on which the restriction occurs.
+
+
+
Description:
+
The day could either be defined as either a Date or as a Day.
+
+
+
Multiplicity:
+
0..*
+
+
+
+
+
+
+
Attribute: startDate
+
+
+
+
+
+
+
+
+
Value type:
+
DayOrDate
+
+
+
Definition:
+
Day on which the restriction ends.
+
+
+
Multiplicity:
+
0..1
+
+
+
+
+
+
+
Attribute: endDate
+
+
+
+
+
+
+
+
+
Value type:
+
DayOrDate
+
+
+
Definition:
+
Day on which the restriction ends.
+
+
+
Multiplicity:
+
0..1
+
+
+
+
+
+
+
Attribute: startTime
+
+
+
+
+
+
+
+
+
Value type:
+
ClockTime
+
+
+
Definition:
+
Time defining when the controlled activity starts.
+
+
+
Description:
+
+
+
+
Multiplicity:
+
0..1
+
+
+
+
+
+
+
Attribute: endTime
+
+
+
+
+
+
+
+
+
Value type:
+
ClockTime
+
+
+
Definition:
+
Time defining when the controlled activity starts. --Description NOTE if the endTime is empty then it shall be inferred that the restriction applies for 24 hours.
+
+
+
Multiplicity:
+
0..1
+
+
+
+
+
+
+
Constraint: At least one of day or startDate and endDate is required
+
+
+
+
+
+
+
+
+
Natural language:
+
+
+
+
OCL:
+
+
+
+
+
+
+
+
+
+
+
5.4.2.3. Code lists
+
+
5.4.2.3.1. ControlledActivityType
+
+
+
+
+
+
+
ControlledActivityType
+
+
+
+
+
+
+
+
+
+
+
+
Definition:
+
Classification of the types of activities controlled within the zone.
+
+
+
Description:
+
A zone may be contain a number of activities that are controlled via regulation/restriction
The allowed values for this code list comprise any values defined by data providers. INSPIRE Registry includes recommended values that may be used by data providers.
+
+
+
+
+
+
+
+
+
+
5.4.2.4. Imported types (informative)
+
+
This section lists definitions for feature types, data types and code lists that are defined in other application schemas. The section is purely informative and should help the reader understand the feature catalogue presented in the previous sections. For the normative documentation of these types, see the given references.
+
+
+
5.4.2.4.1. CharacterString
+
+
+
+
+
+
+
CharacterString
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
Text
+
+
+
Reference:
+
Geographic information — Conceptual schema language [ISO/TS 19103:2005]
+
+
+
+
+
+
+
+
+
5.4.2.4.2. ClockTime
+
+
+
+
+
+
+
ClockTime
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
Date and Time
+
+
+
Reference:
+
Geographic information — Conceptual schema language [ISO/TS 19103:2005]
+
+
+
+
+
+
+
+
+
5.4.2.4.3. Date
+
+
+
+
+
+
+
Date
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
Date and Time
+
+
+
Reference:
+
Geographic information — Conceptual schema language [ISO/TS 19103:2005]
+
+
+
+
+
+
+
+
+
+
+
5.4.3. Externally governed code lists
+
+
Within the Controlled Activities application schema, it is expected that the values that should be included in the SpecialisedActivityTypeCode are derived from externally governed code lists maintained by thematic communities or Member States. To date, no such externally governed code lists have been identified.
+
+
+
+
+
+
+
+
6. Reference systems, units of measure and grids
+
+
+
6.1. Default reference systems, units of measure and grid
+
+
The reference systems, units of measure and geographic grid systems included in this sub-section are the defaults to be used for all INSPIRE data sets, unless theme-specific exceptions and/or additional requirements are defined in section 6.2.
+
+
+
6.1.1. Coordinate reference systems
+
+
6.1.1.1. Datum
+
+
+
+
+
📕
+
+
+
+
IR Requirement
+Annex II, Section 1.2
+Datum for three-dimensional and two-dimensional coordinate reference systems
+
+
+
For the three-dimensional and two-dimensional coordinate reference systems and the horizontal component of compound coordinate reference systems used for making spatial data sets available, the datum shall be the datum of the European Terrestrial Reference System 1989 (ETRS89) in areas within its geographical scope, or the datum of the International Terrestrial Reference System (ITRS) or other geodetic coordinate reference systems compliant with ITRS in areas that are outside the geographical scope of ETRS89. Compliant with the ITRS means that the system definition is based on the definition of the ITRS and there is a well documented relationship between both systems, according to EN ISO 19111.
+
+
+
+
+
+
+
+
6.1.1.2. Coordinate reference systems
+
+
+
+
+
📕
+
+
+
+
IR Requirement
+Annex II, Section 1.3
+Coordinate Reference Systems
+
+
+
Spatial data sets shall be made available using at least one of the coordinate reference systems specified in sections 1.3.1, 1.3.2 and 1.3.3, unless one of the conditions specified in section 1.3.4 holds.
+
+
+
1.3.1. Three-dimensional Coordinate Reference Systems
+
+
+
+
+
Three-dimensional Cartesian coordinates based on a datum specified in 1.2 and using the parameters of the Geodetic Reference System 1980 (GRS80) ellipsoid.
+
+
+
Three-dimensional geodetic coordinates (latitude, longitude and ellipsoidal height) based on a datum specified in 1.2 and using the parameters of the GRS80 ellipsoid.
+
+
+
+
+
1.3.2. Two-dimensional Coordinate Reference Systems
+
+
+
+
+
Two-dimensional geodetic coordinates (latitude and longitude) based on a datum specified in 1.2 and using the parameters of the GRS80 ellipsoid.
+
+
+
Plane coordinates using the ETRS89 Lambert Azimuthal Equal Area coordinate reference system.
+
+
+
Plane coordinates using the ETRS89 Lambert Conformal Conic coordinate reference system.
+
+
+
Plane coordinates using the ETRS89 Transverse Mercator coordinate reference system.
+
+
+
+
+
1.3.3. Compound Coordinate Reference Systems
+
+
+
+
+
+
+
For the horizontal component of the compound coordinate reference system, one of the coordinate reference systems specified in section 1.3.2 shall be used.
+
+
+
For the vertical component, one of the following coordinate reference systems shall be used:
+
+
+
+
+
+
+
+
+
For the vertical component on land, the European Vertical Reference System (EVRS) shall be used to express gravity-related heights within its geographical scope. Other vertical reference systems related to the Earth gravity field shall be used to express gravity-related heights in areas that are outside the geographical scope of EVRS.
+
+
+
For the vertical component in the free atmosphere, barometric pressure, converted to height using ISO 2533:1975 International Standard Atmosphere, or other linear or parametric reference systems shall be used. Where other parametric reference systems are used, these shall be described in an accessible reference using EN ISO 19111-2:2012.
+
+
+
For the vertical component in marine areas where there is an appreciable tidal range (tidal waters), the Lowest Astronomical Tide (LAT) shall be used as the reference surface.
+
+
+
For the vertical component in marine areas without an appreciable tidal range, in open oceans and effectively in waters that are deeper than 200 meters, the Mean Sea Level (MSL) or a well-defined reference level close to the MSL shall be used as the reference surface.
+
+
+
+
+
1.3.4. Other Coordinate Reference Systems
+
+
+
Exceptions, where other coordinate reference systems than those listed in 1.3.1, 1.3.2 or 1.3.3 may be used, are:
+. Other coordinate reference systems may be specified for specific spatial data themes.
+
+
+
+
+
For regions outside of continental Europe, Member States may define suitable coordinate reference systems.
+
+
+
+
+
The geodetic codes and parameters needed to describe these other coordinate reference systems and to allow conversion and transformation operations shall be documented and an identifier shall be created in a coordinate systems register established and operated by the Commission, according to EN ISO 19111 and ISO 19127.
+The Commission shall be assisted by the INSPIRE Commission expert group in the maintenance and update of the coordinate systems register.
+
+
+
+
+
+
+
+
6.1.1.3. Display
+
+
+
+
+
📕
+
+
+
+
IR Requirement
+Annex II, Section 1.4
+Coordinate Reference Systems used in the View Network Service
+
+
+
For the display of spatial data sets with the view network service as specified in Regulation No 976/2009, at least the coordinate reference systems for two-dimensional geodetic coordinates (latitude, longitude) shall be available.
+
+
+
+
+
+
+
+
6.1.1.4. Identifiers for coordinate reference systems
+
+
+
+
+
📕
+
+
+
+
IR Requirement
+Annex II, Section 1.5
+Coordinate Reference System Identifiers
+
+
+
+
+
Coordinate reference system parameters and identifiers shall be managed in one or several common registers for coordinate reference systems.
+
+
+
Only identifiers contained in a common register shall be used for referring to the coordinate reference systems listed in this Section.
+
+
+
+
+
+
+
+
+
These Technical Guidelines propose to use the http URIs provided by the Open Geospatial Consortium as coordinate reference system identifiers (see identifiers for the default CRSs in the INSPIRE coordinate reference systems register). These are based on and redirect to the definition in the EPSG Geodetic Parameter Registry (http://www.epsg-registry.org/).
+
+
+
+
+
+
📒
+
+
+
+
TG Requirement 2
+
+
+
The identifiers listed in the INSPIRE coordinate reference systems register (https://inspire.ec.europa.eu/crs) shall be used for referring to the coordinate reference systems used in a data set.
+
+
+
+
+
+
+
NOTE CRS identifiers may be used e.g. in:
+
+
+
+
+
data encoding,
+
+
+
data set and service metadata, and
+
+
+
requests to INSPIRE network services.
+
+
+
+
+
+
+
6.1.2. Temporal reference system
+
+
+
+
+
📕
+
+
+
+
IR Requirement
+Article 11
+Temporal Reference Systems
+
+
+
+
+
The default temporal reference system referred to in point 5 of part B of the Annex to Commission Regulation (EC) No 1205/2008 ([14]) shall be used, unless other temporal reference systems are specified for a specific spatial data theme in Annex II.
+
+
+
+
+
+
+
+
+
NOTE 1 Point 5 of part B of the Annex to Commission Regulation (EC) No 1205/2008 (the INSPIRE Metadata IRs) states that the default reference system shall be the Gregorian calendar, with dates expressed in accordance with ISO 8601.
+
+
+
NOTE 2 ISO 8601 Data elements and interchange formats – Information interchange – Representation of dates and times is an international standard covering the exchange of date and time-related data. The purpose of this standard is to provide an unambiguous and well-defined method of representing dates and times, so as to avoid misinterpretation of numeric representations of dates and times, particularly when data is transferred between countries with different conventions for writing numeric dates and times. The standard organizes the data so the largest temporal term (the year) appears first in the data string and progresses to the smallest term (the second). It also provides for a standardized method of communicating time-based information across time zones by attaching an offset to Coordinated Universal Time (UTC).
+
+
+
EXAMPLE 1997 (the year 1997), 1997-07-16 (16th July 1997), 1997-07-16T19:20:3001:00 (16th July 1997, 19h 20' 30'', time zone: UTC1)
+
+
+
+
6.1.3. Units of measure
+
+
+
+
+
📕
+
+
+
+
IR Requirement
+Article 12
+Other Requirements & Rules
+
+
+
(…)
+
+
+
+
+
All measurement values shall be expressed using SI units or non-SI units accepted for use with the International System of Units, unless specified otherwise for a specific spatial data theme or type.
+
+
+
+
+
+
+
+
+
+
+
6.2. Theme-specific requirements and recommendations
+
+
There are no theme-specific requirements or recommendations on reference systems and grids.
+
+
+
+
+
+
+
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 Area Management/Restriction/Regulation Zones and Reporting Units (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 Area Management/Restriction/Regulation Zones and Reporting Units (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 Area Management/Restriction/Regulation Zones and Reporting Units (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 4 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 4 – Data quality elements used in the spatial data theme Area Management/Restriction/Regulation Zones and Reporting Units
The Application Schema conformance class of the Abstract Test Suite in Annex I defines a number of tests to evaluate the conceptual consistency (tests A.1.1, A.1.2 and A.1.4-A.1.7) of a data set.
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 11
+
+
+
For the tests on conceptual consistency, it is recommended to use the Logical consistency – Conceptual consistency data quality sub-element and the measure Number of items not compliant with the rules of the conceptual schema as specified in the table below.
+
+
+
+
+
+
+
+
+
+
+
+
+
Name
+
+
+
+
Alternative name
+
-
+
+
+
Data quality element
+
logical consistency
+
+
+
Data quality sub-element
+
conceptual consistency
+
+
+
Data quality basic measure
+
error count
+
+
+
Definition
+
count of all items in the dataset that are not compliant with the rules of the conceptual schema
+
+
+
Description
+
If the conceptual schema explicitly or implicitly describes rules, these rules shall be followed. Violations against such rules can be, for example, invalid placement of features within a defined tolerance, duplication of features and invalid overlap of features.
+
+
+
Evaluation scope
+
spatial object / spatial object type
+
+
+
Reporting scope
+
data set
+
+
+
Parameter
+
-
+
+
+
Data quality value type
+
integer
+
+
+
Data quality value structure
+
-
+
+
+
Source reference
+
ISO/DIS 19157 Geographic information – Data quality
+
+
+
Example
+
+
+
+
Measure identifier
+
10
+
+
+
+
+
+
7.1.2. Logical consistency – Domain consistency
+
+
The Application Schema conformance class of the Abstract Test Suite in Annex I defines a number of tests to evaluate the domain consistency (test A.1.3) of a data set.
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 12
+
+
+
For the tests on domain consistency, it is recommended to use the Logical consistency – Domain consistency data quality sub-element and the measure Number of items not in conformance with their value domain as specified in the table below.
+
+
+
+
+
+
+
+
+
+
+
+
+
Name
+
Number of items not in conformance with their value domain
+
+
+
Alternative name
+
-
+
+
+
Data quality element
+
logical consistency
+
+
+
Data quality sub-element
+
domain consistency
+
+
+
Data quality basic measure
+
error count
+
+
+
Definition
+
count of all items in the dataset that are not in conformance with their value domain
+
+
+
Description
+
+
+
+
Evaluation scope
+
spatial object / spatial object type
+
+
+
Reporting scope
+
data set
+
+
+
Parameter
+
-
+
+
+
Data quality value type
+
integer
+
+
+
+
+
+
+
7.2. Minimum data quality requirements
+
+
No minimum data quality requirements are defined for the spatial data theme Area Management/Restriction/Regulation Zones and Reporting Units.
+
+
+
+
7.3. Recommendation on data quality
+
+
No minimum data quality recommendations are defined.
+
+
+
+
+
+
+
8. Dataset-level metadata
+
+
+
This section specifies dataset-level metadata elements, which should be used for documenting metadata for a complete dataset or dataset series.
+
+
+
NOTE Metadata can also be reported for each individual spatial object (spatial object-level metadata). Spatial object-level metadata is fully described in the application schema(s) (section 5).
+
+
+
For some dataset-level metadata elements, in particular those for reporting data quality and maintenance, a more specific scope can be specified. This allows the definition of metadata at sub-dataset level, e.g. separately for each spatial object type (see instructions for the relevant metadata element).
+
+
+
8.1. Metadata elements defined in INSPIRE Metadata Regulation
+
+
Table 5 gives an overview of the metadata elements specified in Regulation 1205/2008/EC (implementing Directive 2007/2/EC of the European Parliament and of the Council as regards metadata).
+
+
+
The table contains the following information:
+
+
+
+
+
The first column provides a reference to the relevant section in the Metadata Regulation, which contains a more detailed description.
+
+
+
The second column specifies the name of the metadata element.
+
+
+
The third column specifies the multiplicity.
+
+
+
The fourth column specifies the condition, under which the given element becomes mandatory.
+
+
+
+
+
Table 5 – Metadata for spatial datasets and spatial dataset series specified in Regulation 1205/2008/EC
+
+
+
+
+
+
+
+
+
+
+
Metadata Regulation Section
+
Metadata element
+
Multiplicity
+
Condition
+
+
+
1.1
+
Resource title
+
1
+
+
+
+
1.2
+
Resource abstract
+
1
+
+
+
+
1.3
+
Resource type
+
1
+
+
+
+
1.4
+
Resource locator
+
0..*
+
Mandatory if a URL is available to obtain more information on the resource, and/or access related services.
+
+
+
1.5
+
Unique resource identifier
+
1..*
+
+
+
+
1.7
+
Resource language
+
0..*
+
Mandatory if the resource includes textual information.
+
+
+
2.1
+
Topic category
+
1..*
+
+
+
+
3
+
Keyword
+
1..*
+
+
+
+
4.1
+
Geographic bounding box
+
1..*
+
+
+
+
5
+
Temporal reference
+
1..*
+
+
+
+
6.1
+
Lineage
+
1
+
+
+
+
6.2
+
Spatial resolution
+
0..*
+
Mandatory for data sets and data set series if an equivalent scale or a resolution distance can be specified.
+
+
+
7
+
Conformity
+
1..*
+
+
+
+
8.1
+
Conditions for access and use
+
1..*
+
+
+
+
8.2
+
Limitations on public access
+
1..*
+
+
+
+
9
+
Responsible organisation
+
1..*
+
+
+
+
10.1
+
Metadata point of contact
+
1..*
+
+
+
+
10.2
+
Metadata date
+
1
+
+
+
+
10.3
+
Metadata language
+
1
+
+
+
+
+
+
Generic guidelines for implementing these elements using ISO 19115 and 19119 are available at http://inspire.jrc.ec.europa.eu/index.cfm/pageid/101. The following sections describe additional theme-specific recommendations and requirements for implementing these elements.
+
+
+
8.1.1. Conformity
+
+
The Conformity metadata element defined in Regulation 1205/2008/EC requires to report the conformance with the Implementing Rule for interoperability of spatial data sets and services.
+
+
+
NOTE See Part 1 of the Abstract Test Suite in Annex A for further details on testing the conformance with the Implementing Rule.
+
+
+
In addition, the Conformity metadata element may be used also to document the conformance to another specification.
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 13
+
+
+
Dataset metadata should include a statement on the overall conformance of the dataset with this data specification.
+
+
+
+
+
+
+
NOTE See Part 3 of the Abstract Test Suite in Annex A for further details on testing the conformance with the data specification.
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 14
+
+
+
The Conformity metadata element should be used to document conformance with this data specification (as a whole), with a specific conformance class defined in the Abstract Test Suite in Annex A and/or with another specification.
+
+
+
+
+
+
+
The Conformity element includes two sub-elements, the Specification (a citation of the Implementing Rule for interoperability of spatial data sets and services or other specification), and the Degree of conformity. The Degree can be Conformant (if the dataset is fully conformant with the cited specification), Not Conformant (if the dataset does not conform to the cited specification) or Not Evaluated (if the conformance has not been evaluated).
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 15
+
+
+
If a dataset is not yet conformant with all requirements of this data specification, it is recommended to include information on the conformance with the individual conformance classes specified in the Abstract Test Suite in Annex A.
+
+
+
+
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 16
+
+
+
If a dataset is produced or transformed according to an external specification that includes specific quality assurance procedures, the conformity with this specification should be documented using the Conformity metadata element.
+
+
+
+
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 17
+
+
+
If minimum data quality recommendations are defined then the statement on the conformity with these requirements should be included using the Conformity metadata element and referring to the relevant data quality conformance class in the Abstract Test Suite.
+
+
+
+
+
+
+
NOTE Currently no minimum data quality requirements are included in the IRs. The recommendation above should be included as a requirement in the IRs if minimum data quality requirements are defined at some point in the future.
+
+
+
+
8.1.2. Lineage
+
+
+
+
+
📘
+
+
+
+
Recomendation 18
+
+
+
Following the ISO/DIS 19157 Quality principles, if a data provider has a procedure for the quality management of their spatial data sets then the appropriate data quality elements and measures defined in ISO/DIS 19157 should be used to evaluate and report (in the metadata) the results. If not, the Lineage metadata element (defined in Regulation 1205/2008/EC) should be used to describe the overall quality of a spatial data set.
+
+
+
+
+
+
+
According to Regulation 1205/2008/EC, lineage "is a statement on process history and/or overall quality of the spatial data set. Where appropriate it may include a statement whether the data set has been validated or quality assured, whether it is the official version (if multiple versions exist), and whether it has legal validity. The value domain of this metadata element is free text".
+
+
+
The Metadata Technical Guidelines based on EN ISO 19115 and EN ISO 19119 specifies that the statement sub-element of LI_Lineage (EN ISO 19115) should be used to implement the lineage metadata element.
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 19
+
+
+
To describe the transformation steps and related source data, it is recommended to use the following sub-elements of LI_Lineage:
+
+
+
+
+
For the description of the transformation process of the local to the common INSPIRE data structures, the LI_ProcessStep sub-element should be used.
+
+
+
For the description of the source data the LI_Source sub-element should be used.
+
+
+
+
+
+
+
+
+
NOTE 1 In order to improve the interoperability, domain templates and instructions for using these free text elements (descriptive statements) may be specified here and/or in an Annex of this data specification.
+
+
+
+
8.1.3. Temporal reference
+
+
According to Regulation 1205/2008/EC, at least one of the following temporal reference metadata sub-elements shall be provided: temporal extent, date of publication, date of last revision, date of creation.
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 20
+
+
+
It is recommended that at least the date of the last revision of a spatial data set should be reported using the Date of last revision metadata sub-element.
+
+
+
+
+
+
+
+
8.1.4. Lineage: Derived geometries for ManagementRestrictionOrRegulationZone
+
+
+
+
+
📕
+
+
+
+
IR Requirement
+Annex IV, Section 11.4.1
+Theme-specific Requirements – Management Restriction Or Regulation Zones
+
+
+
+
+
If the geometries of the spatial objects in a ManagementRestrictionOrRegulationZone data set are derived from the geometries of spatial objects in another data set, then this source data set (including its version) shall be described as part of the lineage metadata element.
+
+
+
+
+
+
+
+
+
+
8.1.5. Resource Abstract
+
+
The Resource Abstract metadata element defined in Regulation 1205/2008/EC allows to provide a brief summary of the content of the resource.
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 21
+
+
+
To enable effective discovery of specific types of ManagementRestrictionOrRegulationZone data sets, providers should include the following information in the resource abstract:
+
+
+
+
+
Type of zone or name of the spatial object that forms the reporting unit
+
+
+
Official full name of legislation that requires the establishment of the zone or reporting requirements
+
+
+
+
+
+
+
+
+
EXAMPLE 1 Air Quality Management Zones for Slovakia defined as required under Article 4 of the 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 should be encoded like this:
+
+
+
+
<gmd:abstract>
+ <gco:CharacterString>Air Quality Management Zones for Slovakia defined as required under Article 4 of the 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</gco:CharacterString>
+</gmd:abstract>
+
+
+
+
EXAMPLE 2 Air Quality Management Zone Reporting Units for the 2011 reporting period for the 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 should be encoded like this:
+
+
+
+
<gmd:abstract>
+ <gco:CharacterString>Air Quality Management Zone Reporting Units for the 2011 reporting period for the 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</gco:CharacterString>
+</gmd:abstract>
+
+
+
+
+
8.1.6. Keywords
+
+
Keywords are used to classify the resource to facilitate effective discovery and thematic discovery. The keyword value is a commonly used word, formalised word or phrase used to describe the subject and thus help narrowing a full text search and they allow for structured keyword search.
+
+
+
Since the ManagementRestrictionOrRegulationZone spatial object type is generic, data sets related to the theme Area Management/Restriction/Regulation Zones and Reporting Units may contain spatial objects of different zone types, designated under different legal acts and related to different environmental domains. To make it easier for users to discover those Area Management/Restriction/Regulation Zones and Reporting Units data sets that are relevant for a specific task, this data specification requires and recommends and number of additional keywords.
+
+
+
+
+
+
📕
+
+
+
+
IR Requirement
+Annex IV, Section 11.4.1
+
+
+
Theme-specific Requirements – Management Restriction Or Regulation Zones
+
+
+
+
+
Data providers shall include the following keywords in addition to the mandatory keywords defined in Regulation (EC) 1205/2008:
+
+
+
+
One or several keywords describing the high-level classification of the zone type(s) included in the data set, as defined in ZoneTypeCode code list.
+
+
+
One or several keywords describing the official document number(s) of the legal instrument(s) under which the zone(s) included in the data set is (are) established. For Union legislation, the CELEX number shall be used.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 22
+
+
+
For the keyword describing the high-level classification of the zone type(s) included in the data set, the natural language name of value in the ZoneTypeCode code list should be used as the keyword. The originating controlled vocabulary should be specified as follows:
+
+
+
+
+
Title: INSPIRE ZoneTypeCode code list
+
+
+
Date type: publication
+
+
+
Date: 2013-02-04
+
+
+
+
+
+
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 23
+
+
+
Data providers should also include the following keywords:
+
+
+
+
+
Where applicable, one or several keywords describing the classification of the specialised zone type(s) included in the data set, as defined in the relevant code list (section 5.2.3). The natural language name of the specialised zone type should be used as the keyword. The originating controlled vocabulary should clearly identify the code list used for describing the specialized zone type.
+
+
+
One or several keywords describing the official or commonly used short name(s) and/or the commonly used acronym(s) of the legal acts under which the zone(s) included in the data set is (are) established.
+
+
+
One or several keywords describing the environmental domain(s) of the zones included in the data sets, as defined in EnvironmentalDomain code list (section 5.2.3). The natural language name should be used as the keyword. The originating controlled vocabulary should be specified as follows:
+
+
+
+
Title: INSPIRE EnvironmentalDomain code list
+
+
+
Date type: publication
+
+
+
Date: 2013-02-04
+
+
+
+
+
+
+
+
+
+
+
+
EXAMPLE 1 For River Basin Districts, the following keywords shall/should be provided:
+
+
+
+
+
River Basin District (zone type, required)
+
+
+
32000L0060 (official document number (CELEX), required)
+
+
+
Water Framework Directive (legislation short name, recommended)
+
+
+
WFD (legislation acronym, recommended)
+
+
+
water (environmental domain, recommended)
+
+
+
+
+
EXAMPLE 2 For Air Quality Management Zones, the following keywords shall/should be provided:
+
+
+
+
+
Air Quality Management Zone (zone type, required)
+
+
+
32008L0050 (official document number (CELEX), required)
+
+
+
AQD Directive (legislation short name, recommended)
+
+
+
air (environmental domain, recommended)
+
+
+
health protection (environmental domain, recommended)
+
+
+
+
+
NOTE The recommendations for encoding the metadata in Recommendation 22 and Recommendation 23 touch on the larger issue of how to treat metadata keywords that come from a controlled vocabulary (like in this case or GEMET). Ideally, both a code and a human-readable label (in any language) should be included in the metadata, in the same way as is now proposed for providing code list values in the data encoding (see D2.7 Encoding Guidelines). This issue should be addressed in the next update of the Metadata Technical Guidelines.
+
+
+
+
+
8.2. Metadata elements for interoperability
+
+
+
+
+
📕
+
+
+
+
IR Requirement
+Article 13
+Metadata required for Interoperability
+
+
+
The metadata describing a spatial data set shall include the following metadata elements required for interoperability:
+
+
+
+
+
Coordinate Reference System: Description of the coordinate reference system(s) used in the data set.
+
+
+
Temporal Reference System: Description of the temporal reference system(s) used in the data set.
+
+
This element is mandatory only if the spatial data set contains temporal information that does not refer to the default temporal reference system.
+
+
+
+
Encoding: Description of the computer language construct(s) specifying the representation of data objects in a record, file, message, storage device or transmission channel.
+
+
+
Topological Consistency: Correctness of the explicitly encoded topological characteristics of the data set as described by the scope.
+
+
This element is mandatory only if the data set includes types from the Generic Network Model and does not assure centreline topology (connectivity of centrelines) for the network.
+
+
+
+
Character Encoding: The character encoding used in the data set.
+
+
This element is mandatory only if an encoding is used that is not based on UTF-8.
+
+
+
+
Spatial Representation Type: The method used to spatially represent geographic information.
+
+
+
+
+
+
+
+
+
These Technical Guidelines propose to implement the required metadata elements based on ISO 19115 and ISO/TS 19139.
+
+
+
The following TG requirements need to be met in order to be conformant with the proposed encoding.
+
+
+
+
+
+
📒
+
+
+
+
TG Requirement 3
+
+
+
Metadata instance (XML) documents shall validate without error against the used ISO 19139 XML schema.
+
+
+
+
+
+
+
NOTE Section 2.1.2 of the Metadata Technical Guidelines discusses the different ISO 19139 XML schemas that are currently available.
+
+
+
+
+
+
📒
+
+
+
+
TG Requirement 4
+
+
+
Metadata instance (XML) documents shall contain the elements and meet the INSPIRE multiplicity specified in the sections below.
+
+
+
+
+
+
+
+
+
+
📒
+
+
+
+
TG Requirement 5
+
+
+
The elements specified below shall be available in the specified ISO/TS 19139 path.
+
+
+
+
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 24
+
+
+
The metadata elements for interoperability should be made available together with the metadata elements defined in the Metadata Regulation through an INSPIRE discovery service.
+
+
+
+
+
+
+
NOTE While this not explicitly required by any of the INSPIRE Implementing Rules, making all metadata of a data set available together and through one service simplifies implementation and usability.
+
+
+
8.2.1. Coordinate Reference System
+
+
+
+
+
+
+
+
Metadata element name
+
Coordinate Reference System
+
+
+
Definition
+
Description of the coordinate reference system used in the dataset.
+
+
+
ISO 19115 number and name
+
13. referenceSystemInfo
+
+
+
ISO/TS 19139 path
+
referenceSystemInfo
+
+
+
INSPIRE obligation / condition
+
mandatory
+
+
+
INSPIRE multiplicity
+
1..*
+
+
+
Data type(and ISO 19115 no.)
+
186. MD_ReferenceSystem
+
+
+
Domain
+
+
To identify the reference system, the referenceSystemIdentifier (RS_Identifier) shall be provided.
+
+
+
NOTE More specific instructions, in particular on pre-defined values for filling the referenceSystemIdentifier attribute should be agreed among Member States during the implementation phase to support interoperability.
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.
Description of the computer language construct that specifies the representation of data objects in a record, file, message, storage device or transmission channel
See B.2.10.4. The property values (name, version, specification) specified in section 5 shall be used to document the default and alternative encodings.
+
+
+
Implementing instructions
+
+
+
+
Example
+
+
name: <Application schema name> GML application schema
+version: version 3.0
+specification: D2.8.III.11 Data Specification on Area Management/Restriction/Regulation Zones and Reporting Units – Technical Guidelines
+
+
+
+
Example XML encoding
+
+
+
<gmd:MD_Format>
+ <gmd:name>
+ <gco:CharacterString>SomeApplicationSchema GML application schema</gco:CharacterString>
+ </gmd:name>
+ <gmd:version>
+ <gco:CharacterString>3.0</gco:CharacterString>
+ </gmd:version>
+ <gmd:specification>
+ <gco:CharacterString>D2.8.III.11 Data Specification on Area Management/Restriction/Regulation Zones and Reporting Units – Technical Guidelines</gco:CharacterString>
+ </gmd:specification>
+</gmd:MD_Format>
+
+
+
+
+
Comments
+
+
+
+
+
+
+
8.2.4. Character Encoding
+
+
+
+
+
+
+
+
Metadata element name
+
Character Encoding
+
+
+
Definition
+
The character encoding used in the data set.
+
+
+
ISO 19115 number and name
+
+
+
+
ISO/TS 19139 path
+
+
+
+
INSPIRE obligation / condition
+
Mandatory, if an encoding is used that is not based on UTF-8.
The method used to spatially represent geographic information.
+
+
+
ISO 19115 number and name
+
37. spatialRepresentationType
+
+
+
ISO/TS 19139 path
+
+
+
+
INSPIRE obligation / condition
+
Mandatory
+
+
+
INSPIRE multiplicity
+
1..*
+
+
+
Data type (and ISO 19115 no.)
+
B.5.26 MD_SpatialRepresentationTypeCode
+
+
+
Domain
+
+
+
+
Implementing instructions
+
+
Of the values included in the code list in ISO 19115 (vector, grid, textTable, tin, stereoModel, video), only vector, grid and tin should be used.
+
+
+
NOTE Additional code list values may be defined based on feedback from implementation.
+
+
+
+
Example
+
-
+
+
+
Example XML encoding
+
+
+
+
Comments
+
+
+
+
+
+
+
8.2.6. Data Quality – Logical Consistency – Topological Consistency
+
+
See section 8.3.2 for instructions on how to implement metadata elements for reporting data quality.
+
+
+
+
+
8.3. Recommended theme-specific metadata elements
+
+
+
+
+
📘
+
+
+
+
Recomendation 25
+
+
+
The metadata describing a spatial data set or a spatial data set series related to the theme Area Management/Restriction/Regulation Zones and Reporting Units should comprise the theme-specific metadata elements specified in Table 6.
+
+
+
+
+
+
+
The table contains the following information:
+
+
+
+
+
The first column provides a reference to a more detailed description.
+
+
+
The second column specifies the name of the metadata element.
+
+
+
The third column specifies the multiplicity.
+
+
+
+
+
Table 6 – Optional theme-specific metadata elements for the theme Area Management/Restriction/Regulation Zones and Reporting Units
+
+
+
+
+
+
+
+
+
+
Section
+
Metadata element
+
Multiplicity
+
+
+
8.3.1
+
Maintenance Information
+
0..1
+
+
+
8.3.2
+
Logical Consistency – Conceptual Consistency
+
0..*
+
+
+
8.3.2
+
Logical Consistency – Domain Consistency
+
0..*
+
+
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 26
+
+
+
For implementing the metadata elements included in this section using ISO 19115, ISO/DIS 19157 and ISO/TS 19139, the instructions included in the relevant sub-sections should be followed.
+
+
+
+
+
+
+
8.3.1. Maintenance Information
+
+
+
+
+
+
+
+
Metadata element name
+
Maintenance information
+
+
+
Definition
+
Information about the scope and frequency of updating
This is a complex type (lines 143-148 from ISO 19115).
+At least the following elements should be used (the multiplicity according to ISO 19115 is shown in parentheses):
+
+
+
+
+
maintenanceAndUpdateFrequency [1]: frequency with which changes and additions are made to the resource after the initial resource is completed / domain value: MD_MaintenanceFrequencyCode:
+
+
+
updateScope [0..*]: scope of data to which maintenance is applied / domain value: MD_ScopeCode
+
+
+
maintenanceNote [0..*]: information regarding specific requirements for maintaining the resource / domain value: free text
+
+
+
+
+
+
Implementing instructions
+
+
+
+
Example
+
+
+
+
Example XML encoding
+
+
+
+
Comments
+
+
+
+
+
+
+
8.3.2. Metadata elements for reporting data quality
+
+
+
+
+
📘
+
+
+
+
Recomendation 27
+
+
+
For reporting the results of the data quality evaluation, the data quality elements, sub-elements and (for quantitative evaluation) measures defined in chapter 7 should be used.
+
+
+
+
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 28
+
+
+
The metadata elements specified in the following sections should be used to report the results of the data quality evaluation. At least the information included in the row "Implementation instructions" should be provided.
+
+
+
+
+
+
+
The first section applies to reporting quantitative results (using the element DQ_QuantitativeResult), while the second section applies to reporting non-quantitative results (using the element DQ_DescriptiveResult).
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 29
+
+
+
If a dataset does not pass the tests of the Application schema conformance class (defined in Annex A), the results of each test should be reported using one of the options described in sections 8.3.2.1 and 8.3.2.2.
+
+
+
+
+
+
+
NOTE 1 If using non-quantitative description, the results of several tests do not have to be reported separately, but may be combined into one descriptive statement.
+
+
+
NOTE 2 The sections 8.3.2.1 and 8.3.2.2 may need to be updated once the XML schemas for ISO 19157 have been finalised.
+
+
+
The scope for reporting may be different from the scope for evaluating data quality (see section 7). If data quality is reported at the data set or spatial object type level, the results are usually derived or aggregated.
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 30
+
+
+
The scope element (of type DQ_Scope) of the DQ_DataQuality subtype should be used to encode the reporting scope.
+
+
+
Only the following values should be used for the level element of DQ_Scope: Series, Dataset, featureType.
+
+
+
If the level is featureType the levelDescription/MDScopeDescription/features element (of type Set< GF_FeatureType>) shall be used to list the feature type names.
+
+
+
+
+
+
+
NOTE In the level element of DQ_Scope, the value featureType is used to denote spatial object type.
+
+
+
8.3.2.1. Guidelines for reporting quantitative results of the data quality evaluation
+
+
+
+
+
+
+
+
Metadata element name
+
See chapter 7
+
+
+
Definition
+
See chapter 7
+
+
+
ISO/DIS 19157 number and name
+
3. report
+
+
+
ISO/TS 19139 path
+
dataQualityInfo/*/report
+
+
+
INSPIRE obligation / condition
+
optional
+
+
+
INSPIRE multiplicity
+
0..*
+
+
+
Data type (and ISO/DIS 19157 no.)
+
Corresponding DQ_xxx subelement from ISO/DIS 19157, e.g. 12. DQ_CompletenessCommission
+
+
+
Domain
+
+
Lines 7-9 from ISO/DIS 19157
+
+
+
+
+
DQ_MeasureReference (C.2.1.3)
+
+
+
DQ_EvaluationMethod (C.2.1.4.)
+
+
+
DQ_Result (C2.1.5.)
+
+
+
+
+
+
Implementing instructions
+
+
+
+
nameOfMeasure
+
+
+
+
+
NOTE This should be the name as defined in Chapter 7.
+
+
+
+
+
evaluationMethodType
+
+
+
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.
+
+
+
+
+
dateTime
+
+
+
+
+
NOTE This should be data or range of dates on which the data quality measure was applied.
+
+
+
+
+
DQ_QuantitativeResult / 64. value
+
+
+
+
+
NOTE The DQ_Result type should be DQ_QuantitativeResult and the value(s) represent(s) the application of the data quality measure (39.) using the specified evaluation method (42-43.)
+
+
+
+
Example
+
See Table E.12 — Reporting commission as metadata (ISO/DIS 19157)
+
+
+
Example XML encoding
+
+
+
+
+
+
+
8.3.2.2. Guidelines for reporting descriptive results of the Data Quality evaluation
+
+
+
+
+
+
+
+
Metadata element name
+
See chapter 7
+
+
+
Definition
+
See chapter 7
+
+
+
ISO/DIS 19157 number and name
+
3. report
+
+
+
ISO/TS 19139 path
+
dataQualityInfo/*/report
+
+
+
INSPIRE obligation / condition
+
optional
+
+
+
INSPIRE multiplicity
+
0..*
+
+
+
Data type (and ISO/DIS 19157 no.)
+
Corresponding DQ_xxx subelement from ISO/DIS 19157, e.g. 12. DQ_CompletenessCommission
+
+
+
Domain
+
+
Line 9 from ISO/DIS 19157
+
+
+
+
+
DQ_Result (C2.1.5.)
+
+
+
+
+
+
Implementing instructions
+
+
+
+
DQ_DescripitveResult / 68. statement
+
+
+
+
+
NOTE The DQ_Result type should be DQ_DescriptiveResult and in the statement (68.) the evaluation of the selected DQ sub-element should be expressed in a narrative way.
+
+
+
+
Example
+
See Table E.15 — Reporting descriptive result as metadata (ISO/DIS 19157)
+
+
+
Example XML encoding
+
+
+
+
+
+
+
+
+
+
+
+
9. Delivery
+
+
+
9.1. Updates
+
+
+
+
+
📕
+
+
+
+
IR Requirement
+Article 8
+Updates
+
+
+
+
+
Member States shall make available updates of data on a regular basis.
+
+
+
All updates shall be made available at the latest 6 months after the change was applied in the source data set, unless a different period is specified for a specific spatial data theme in Annex II.
+
+
+
+
+
+
+
+
+
NOTE In this data specification, no exception is specified, so all updates shall be made available at the latest 6 months after the change was applied in the source data set.
+
+
+
+
9.2. Delivery medium
+
+
According to Article 11(1) of the INSPIRE Directive, Member States shall establish and operate a network of services for INSPIRE spatial data sets and services. The relevant network service types for making spatial data available are:
+
+
+
+
+
view services making it possible, as a minimum, to display, navigate, zoom in/out, pan, or overlay viewable spatial data sets and to display legend information and any relevant content of metadata;
+
+
+
download services, enabling copies of spatial data sets, or parts of such sets, to be downloaded and, where practicable, accessed directly;
+
+
+
transformation services, enabling spatial data sets to be transformed with a view to achieving interoperability.
+
+
+
+
+
NOTE For the relevant requirements and recommendations for network services, see the relevant Implementing Rules and Technical Guidelines[15].
+
+
+
EXAMPLE 1 Through the Get Spatial Objects function, a download service can either download a pre-defined data set or pre-defined part of a data set (non-direct access download service), or give direct access to the spatial objects contained in the data set, and download selections of spatial objects based upon a query (direct access download service). To execute such a request, some of the following information might be required:
+
+
+
+
+
the list of spatial object types and/or predefined data sets that are offered by the download service (to be provided through the Get Download Service Metadata operation),
+
+
+
and the query capabilities section advertising the types of predicates that may be used to form a query expression (to be provided through the Get Download Service Metadata operation, where applicable),
+
+
+
a description of spatial object types offered by a download service instance (to be provided through the Describe Spatial Object Types operation).
+
+
+
+
+
EXAMPLE 2 Through the Transform function, a transformation service carries out data content transformations from native data forms to the INSPIRE-compliant form and vice versa. If this operation is directly called by an application to transform source data (e.g. obtained through a download service) that is not yet conformant with this data specification, the following parameters are required:
+
+
+
Input data (mandatory). The data set to be transformed.
+
+
+
+
+
Source model (mandatory, if cannot be determined from the input data). The model in which the input data is provided.
+
+
+
Target model (mandatory). The model in which the results are expected.
+
+
+
Model mapping (mandatory, unless a default exists). Detailed description of how the transformation is to be carried out.
+
+
+
+
+
+
9.3. Encodings
+
+
The IRs contain the following two requirements for the encoding to be used to make data available.
+
+
+
+
+
+
📕
+
+
+
+
IR Requirement
+Article 7
+Encoding
+
+
+
1. Every encoding rule used to encode spatial data shall conform to EN ISO 19118. In particular, it shall specify schema conversion rules for all spatial object types and all attributes and association roles and the output data structure used.
+
+
+
2. Every encoding rule used to encode spatial data shall be made available.
+
+
+
2a. Every encoding rule used to encode spatial data shall also specify whether and how to represent attributes and association roles for which a corresponding value exists but is not contained in the spatial data sets maintained by a Member State, or cannot be derived from existing values at reasonable costs.
+
+
+
+
+
+
+
NOTE ISO 19118:2011 specifies the requirements for defining encoding rules used for interchange of geographic data within the set of International Standards known as the "ISO 19100 series". An encoding rule allows geographic information defined by application schemas and standardized schemas to be coded into a system-independent data structure suitable for transport and storage. The encoding rule specifies the types of data being coded and the syntax, structure and coding schemes used in the resulting data structure. Specifically, ISO 19118:2011 includes
+
+
+
+
+
requirements for creating encoding rules based on UML schemas,
+
+
+
requirements for creating encoding services, and
+
+
+
requirements for XML-based encoding rules for neutral interchange of data.
+
+
+
+
+
While the IRs do not oblige the usage of a specific encoding, these Technical Guidelines propose to make data related to the spatial data theme Area Management/Restriction/Regulation Zones and Reporting Units available at least in the default encoding(s) specified in section 0. In this section, a number of TG requirements are listed that need to be met in order to be conformant with the default encoding(s).
+
+
+
The proposed default encoding(s) meet the requirements in Article 7 of the IRs, i.e. they are conformant with ISO 19118 and (since they are included in this specification) publicly available.
+
+
+
9.3.1. Default Encoding(s)
+
+
9.3.1.1. Specific requirements for GML encoding
+
+
This data specification proposes the use of GML as the default encoding, as recommended in sections 7.2 and 7.3 of [DS-D2.7]. GML is an XML encoding in compliance with ISO 19118, as required in Article 7(1). For details, see [ISO 19136], and in particular Annex E (UML-to-GML application schema encoding rules).
+
+
+
The following TG requirements need to be met in order to be conformant with GML encodings.
+
+
+
+
+
+
📒
+
+
+
+
TG Requirement 6
+
+
+
Data instance (XML) documents shall validate without error against the provided XML schema.
+
+
+
+
+
+
+
NOTE 1 Not all constraints defined in the application schemas can be mapped to XML. Therefore, the following requirement is necessary.
+
+
+
NOTE 2 The obligation to use only the allowed code list values specified for attributes and most of the constraints defined in the application schemas cannot be mapped to the XML sch. They can therefore not be enforced through schema validation. It may be possible to express some of these constraints using other schema or rule languages (e.g. Schematron), in order to enable automatic validation.
+
+
+
+
9.3.1.2. Default encoding(s) for application schema Area Management, Restriction and Regulation Zones
+
+
Name: Area Management, Restriction and Regulation Zones GML Application Schema
+Version: version 3.0
+Specification: D2.8.III.11 Data Specification on Area Management/Restriction/Regulation Zones and Reporting Units – Technical Guidelines
+Character set: UTF-8
The encoding rule used for this encoding is specified in Annex B of [DS-D2.7].
+
+
+
NOTE Annex B of [DS-D2.7], version 3.3rc2, requires that the "encoding rule specified in ISO 19136 Annex E with the extensions in GML 3.3 shall be applied with the additional rules stated in this Annex. For types within the scope of the ISO/TS 19139 encoding rule, the encoding rule of ISO/TS 19139 shall be applied."
+
+
+
+
+
9.3.1.3. Default encoding(s) for application schema Controlled Activities
+
+
Name: Controlled Activities GML Application Schema
+Version: version 3.0
+Specification: D2.8.III.11 Data Specification on Area Management/Restriction/Regulation Zones and Reporting Units – Technical Guidelines
+Character set: UTF-8
The encoding rule used for this encoding is specified in Annex B of [DS-D2.7].
+
+
+
NOTE Annex B of [DS-D2.7], version 3.3rc2, requires that the "encoding rule specified in ISO 19136 Annex E with the extensions in GML 3.3 shall be applied with the additional rules stated in this Annex. For types within the scope of the ISO/TS 19139 encoding rule, the encoding rule of ISO/TS 19139 shall be applied."
+
+
+
+
+
+
9.3.2. Recommended Encoding(s)
+
+
+
+
+
📘
+
+
+
+
Recomendation 31
+
+
+
It is recommended that also the encodings specified in this section be provided for the relevant application schemas.
+
+
+
+
+
+
+
No alternative encodings are specified for this theme.
+
+
+
+
+
+
+
+
10. Data Capture
+
+
+
There is no specific guidance required with respect to data capture.
+
+
+
+
+
+
11. Portrayal
+
+
+
This clause defines the rules for layers and styles to be used for portrayal of the spatial object types defined for this theme. Portrayal is regulated in Article 14 of the IRs.
+
+
+
+
+
+
📕
+
+
+
+
IR Requirement
+Article 14
+Portrayal
+
+
+
+
+
For the portrayal of spatial data sets using a view network service as specified in Commission Regulation No 976/2009 ([16]), the following shall be available:
+
+
+
+
the layers specified in Annex II for the theme or themes the data set is related to;
+
+
+
for each layer at least a default portrayal style, with as a minimum an associated title and a unique identifier.
+
+
+
+
+
+
+
+
+
+
For each layer, Annex II defines the following:
+
+
+
+
a human readable title of the layer to be used for display in user interface;
+
+
+
the spatial object type(s), or sub-set thereof, that constitute(s) the content of the layer.
+
+
+
+
+
+
+
+
+
+
+
+
In section 11.1, the types of layers are defined that are to be used for the portrayal of the spatial object types defined in this specification. A view service may offer several layers of the same type, one for each dataset that it offers data on a specific topic.
+
+
+
NOTE The layer specification in the IRs only contains the name, a human readable title and the (subset(s) of) spatial object type(s), that constitute(s) the content of the layer. In addition, these Technical Guidelines suggest keywords for describing the layer.
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 32
+
+
+
It is recommended to use the keywords specified in section 11.1 in the Layers Metadata parameters of the INSPIRE View service (see Annex III, Part A, section 2.2.4 in Commission Regulation (EC) No 976/2009).
+
+
+
+
+
+
+
Section 11.2 specifies one style for each of these layers. It is proposed that INSPIRE view services support this style as the default style required by Article 14(1b).
+
+
+
+
+
+
📒
+
+
+
+
TG Requirement 7
+
+
+
For each layer specified in this section, the styles defined in section 11.2 shall be available.
+
+
+
+
+
+
+
NOTE The default style should be used for portrayal by the view network service if no user-defined style is specified in a portrayal request for a specific layer.
+
+
+
In section 11.3, further styles can be specified that represent examples of styles typically used in a thematic domain. It is recommended that also these styles should be supported by INSPIRE view services, where applicable.
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 33
+
+
+
In addition, it is recommended that, where applicable, INSPIRE view services also support the styles defined in section 11.3.
+
+
+
+
+
+
+
Where XML fragments are used in the following sections, the following namespace prefixes apply:
+
+
+
+
+
sld="http://www.opengis.net/sld" (WMS/SLD 1.1)
+
+
+
se="http://www.opengis.net/se" (SE 1.1)
+
+
+
ogc="http://www.opengis.net/ogc" (FE 1.1)
+
+
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 1
+
+
+
If an INSPIRE view services supports the portrayal of data related to the theme Area Management/Restriction/Regulation Zones and Reporting Units, which is not covered by the layers specified in section 11.1 (i.e. data that includes spatial objects of additional zone types), it should provide one layer per additional zone type according to the following template:
+
+
+
+
+
Layer name: AM.<UpperCamelCaseName of the zone type>
+
+
+
Layer title: <Natural language name of the zone type>
+
+
+
Keywords: "management / restriction / regulation zones", <Natural language name of the zone type>
+
+
+
+
+
For these layers, a default style should be defined according to the template included in section 11.2.20.
+
+
+
This style should be supported by the INSPIRE view service, and used if no user-defined style is specified in a portrayal request for the layer.
+
+
+
+
+
+
+
11.1. Layers to be provided by INSPIRE view services
Example:
+management / restriction / regulation zones, air quality management zones
+
+
+
+
+
+
NOTE The table above contains several layers for the spatial object type(s) <spatial object type names>, which can be further classified using a code list-valued attribute. Such sets of layers are specified as described in Article 14(3) of the IRs.
+
+
+
+
+
+
📕
+
+
+
+
IR Requirement
+Article 14
+Portrayal
+
+
+
(…)
+
+
+
+
+
For spatial object types whose objects can be further classified using a code list-valued attribute, several layers may be defined. Each of these layers shall include the spatial objects corresponding to one specific code list value. In the definition of such sets of layers in Annexes II-IV,
+
+
+
+
the placeholder <CodeListValue> shall represent the values of the relevant code list, with the first letter in upper case,
+
+
+
the placeholder <human-readable name> shall represent the human-readable name of the code list values;
+
+
+
the spatial object type shall include the relevant attribute and code list, in parentheses;
+
+
+
one example of a layer shall be given.
+
+
+
+
+
+
+
+
+
+
+
+
For convenience, the layers for all code list values are listed in the table below.
management / restriction / regulation zones, water body under the Water Framework Directive (2000/60/EC)
+
+
+
+
+
11.1.1. Layers organisation
+
+
None.
+
+
+
+
+
11.2. Styles required to be supported by INSPIRE view services
+
+
NOTE The symbology is defined in two SLD/SE fragments describing the layer and style, respectively. An example is given in section 11.2.1 for the layer AM.AirQualityManagementZone. All other layers and styles have equivalent SLD/SE definitions and can be derived by replacing the text in bold with the relevant names, titles, code list values and colour codes.
+
+
+
11.2.1. Styles for the layer AM.AirQualityManagementZone
+
+
+
+
+
+
+
+
Style Name
+
AM.AirQualityManagementZone.Default
+
+
+
+
+
Default Style
+
yes
+
+
+
Style Title
+
Air Quality Management Zone Default Style
+
+
+
Style Abstract
+
The geometry is rendered for points as a square with a size of 6 pixels, with a mango (#FFD37F) fill and a black outline; for curves as a solid mango (#FFD37F) line with a stroke width of 2 pixels; and for surfaces using a mango (#FFD37F) fill with a transparency of 50% and a solid mango (#FFD37F) outline with a stroke width of 2 pixels.
Definition of the user style (UserStyle_AM_AirQualityManagementZone_Default.xml):
+
+
+
+
<?xml version="1.0" encoding="UTF-8"?>
+<sld:UserStyle xmlns:se="http://www.opengis.net/se" xmlns:sld="http://www.opengis.net/sld" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.opengis.net/sld http://schemas.opengis.net/sld/1.1/StyledLayerDescriptor.xsd" xmlns:ogc="http://www.opengis.net/ogc">
+ <se:Name>AM.AirQualityManagementZone.Default</se:Name>
+ <sld:IsDefault>1</sld:IsDefault>
+ <se:FeatureTypeStyle version="1.1.0">
+ <se:Description>
+ <se:Title>Air Quality Management Zone Default Style</se:Title>
+ <se:Abstract>The geometry is rendered for points as a square with a size of 6 pixels, with a mango (#FFD37F) fill and a black outline; for curves as a solid mango (#FFD37F) line with a stroke width of 2 pixels; and for surfaces using a mango (#FFD37F) fill with a transparency of 50% and a solid mango (#FFD37F) outline with a stroke width of 2 pixels.</se:Abstract>
+ </se:Description>
+ <se:FeatureTypeName>ManagementRestrictionOrRegulationZone</se:FeatureTypeName>
+ <se:Rule>
+ <se:PolygonSymbolizer>
+ <se:Geometry>
+ <ogc:PropertyName>geometry</ogc:PropertyName>
+ </se:Geometry>
+ <se:Fill>
+ <se:SvgParameter name="fill">#FFD37F</se:SvgParameter>
+ <se:SvgParameter name="fill-opacity">0.5</se:SvgParameter>
+ </se:Fill>
+ <se:Stroke>
+ <se:SvgParameter name="stroke-width">2</se:SvgParameter>
+ <se:SvgParameter name="stroke">#FFD37F</se:SvgParameter>
+ </se:Stroke>
+ </se:PolygonSymbolizer>
+ <se:LineSymbolizer>
+ <se:Geometry>
+ <ogc:PropertyName>geometry</ogc:PropertyName>
+ </se:Geometry>
+ <se:Stroke>
+ <se:SvgParameter name="stroke-width">2</se:SvgParameter>
+ <se:SvgParameter name="stroke">#FFD37F</se:SvgParameter>
+ </se:Stroke>
+ </se:LineSymbolizer>
+ <se:PointSymbolizer>
+ <se:Graphic>
+ <se:Mark>
+ <se:WellKnownName>square</se:WellKnownName>
+ <se:Fill>
+ <se:SvgParameter name="fill">#FFD37F</se:SvgParameter>
+ </se:Fill>
+ <se:Stroke>
+ <se:SvgParameter name="stroke-width">1</se:SvgParameter>
+ <se:SvgParameter name="stroke">#000000</se:SvgParameter>
+ </se:Stroke>
+ </se:Mark>
+ <se:Size>6</se:Size>
+ </se:Graphic>
+ </se:PointSymbolizer>
+ </se:Rule>
+ </se:FeatureTypeStyle>
+</sld:UserStyle>
+
+
+
+
+
Minimum & maximum scales
+
None
+
+
+
Example
+
+
+
+
+
+
+
+
+
+
+
11.2.2. Styles for the layer AM.AnimalHealthRestrictionZone
+
+
+
+
+
+
+
+
Style Name
+
AM.AnimalHealthRestrictionZone.Default
+
+
+
+
+
Default Style
+
yes
+
+
+
Style Title
+
Animal Health Restriction Zone Default Style
+
+
+
Style Abstract
+
The geometry is rendered for points as a square with a size of 6 pixels, with a red (#FF0000) fill and a black outline; for curves as a solid red (#FF0000) line with a stroke width of 2 pixels; and for surfaces using a red (#FF0000) fill with a transparency of 50% and a solid red (#FF0000) outline with a stroke width of 2 pixels.
+
+
+
Symbology
+
See example in section 11.2.1.
+
+
+
Minimum & maximum scales
+
None
+
+
+
Example
+
+
+
+
+
+
+
+
+
+
+
11.2.3. Styles for the layer AM.AreaForDisposalOfWaste
+
+
+
+
+
+
+
+
Style Name
+
AM.AreaForDisposalOfWaste.Default
+
+
+
+
+
Default Style
+
yes
+
+
+
Style Title
+
Area For Disposal Of Waste Default Style
+
+
+
Style Abstract
+
The geometry is rendered for points as a square with a size of 6 pixels, with a light brown (#CDAA66) fill and a black outline; for curves as a solid light brown line (#CDAA66) with a stroke width of 2 pixels; and for surfaces using a light brown (#CDAA66) fill with a transparency of 50% and a solid light brown (#CDAA66) outline with a stroke width of 2 pixels.
+
+
+
Symbology
+
See example in section 11.2.1.
+
+
+
Minimum & maximum scales
+
None
+
+
+
Example
+
+
+
+
+
+
+
+
+
+
+
11.2.4. Styles for the layer AM.BathingWaters
+
+
+
+
+
+
+
+
Style Name
+
AM.BathingWaters.Default
+
+
+
+
+
Default Style
+
yes
+
+
+
Style Title
+
Bathing Waters Default Style
+
+
+
Style Abstract
+
The geometry is rendered for points as a square with a size of 6 pixels, with a light blue (#BED2FF) fill and a black outline; for curves as a solid light blue line (#BED2FF) with a stroke width of 2 pixels; and for surfaces using a light blue (#BED2FF) fill with a transparency of 50% and a solid light blue (#BED2FF) outline with a stroke width of 2 pixels.
+
+
+
Symbology
+
See example in section 11.2.1.
+
+
+
Minimum & maximum scales
+
None
+
+
+
Example
+
+
+
+
+
+
+
+
+
+
+
11.2.5. Styles for the layer AM.CoastalZoneManagementArea
+
+
+
+
+
+
+
+
Style Name
+
AM.CoastalZoneManagementArea.Default
+
+
+
+
+
Default Style
+
yes
+
+
+
Style Title
+
Coastal Zone Management Area Default Style
+
+
+
Style Abstract
+
The geometry is rendered for points as a square with a size of 6 pixels, with a blue (#85ABFF) fill and a black outline; for curves as a solid blue line (#85ABFF) with a stroke width of 2 pixels; and for surfaces using a blue (#85ABFF) fill with a transparency of 50% and a solid blue (#85ABFF) outline with a stroke width of 2 pixels.
+
+
+
Symbology
+
See example in section 11.2.1.
+
+
+
Minimum & maximum scales
+
None
+
+
+
Example
+
+
+
+
+
+
+
+
+
+
+
11.2.6. Styles for the layer AM.DesignatedWaters
+
+
+
+
+
+
+
+
Style Name
+
AM.DesignatedWaters.Default
+
+
+
+
+
Default Style
+
yes
+
+
+
Style Title
+
Designated Waters Default Style
+
+
+
Style Abstract
+
The geometry is rendered for points as a square with a size of 6 pixels, with a light blue (#BED2FF) fill and a black outline; for curves as a solid light blue line (#BED2FF) with a stroke width of 2 pixels; and for surfaces using a light blue (#BED2FF) fill with a transparency of 50% and a solid light blue (#BED2FF) outline with a stroke width of 2 pixels.
+
+
+
Symbology
+
See example in section 11.2.1.
+
+
+
Minimum & maximum scales
+
None
+
+
+
Example
+
+
+
+
+
+
+
+
+
+
+
11.2.7. Styles for the layer AM.DrinkingWaterProtectionArea
+
+
+
+
+
+
+
+
Style Name
+
AM.DrinkingWaterProtectionArea.Default
+
+
+
+
+
Default Style
+
yes
+
+
+
Style Title
+
Drinking Water Protection Area Default Style
+
+
+
Style Abstract
+
The geometry is rendered for points as a square with a size of 6 pixels, with a light blue (#BED2FF) fill and a black outline; for curves as a solid light blue line (#BED2FF) with a stroke width of 2 pixels; and for surfaces using a light blue (#BED2FF) fill with a transparency of 50% and a solid light blue (#BED2FF) outline with a stroke width of 2 pixels.
+
+
+
Symbology
+
See example in section 11.2.1.
+
+
+
Minimum & maximum scales
+
None
+
+
+
Example
+
+
+
+
+
+
+
+
+
+
+
11.2.8. Styles for the layer AM.FloodUnitOfManagement
+
+
+
+
+
+
+
+
Style Name
+
AM.FloodUnitOfManagement.Default
+
+
+
+
+
Default Style
+
yes
+
+
+
Style Title
+
Flood Unit Of Management Default Style
+
+
+
Style Abstract
+
The geometry is rendered for points as a square with a size of 6 pixels, with a lilac (#9966FF) fill and a black outline; for curves as a solid lilac line (#9966FF) with a stroke width of 2 pixels; and for surfaces using a lilac (#9966FF) fill with a transparency of 50% and a solid lilac (#9966FF) outline with a stroke width of 2 pixels.
+
+
+
Symbology
+
See example in section 11.2.1.
+
+
+
Minimum & maximum scales
+
None
+
+
+
Example
+
+
+
+
+
+
+
+
+
+
+
11.2.9. Styles for the layer AM.ForestManagementArea
+
+
+
+
+
+
+
+
Style Name
+
AM.ForestManagementArea.Default
+
+
+
+
+
Default Style
+
yes
+
+
+
Style Title
+
Forest Management Area Default Style
+
+
+
Style Abstract
+
The geometry is rendered for points as a square with a size of 6 pixels, with a light green (#33CC33) fill and a black outline; for curves as a solid light green line (#33CC33) with a stroke width of 2 pixels; and for surfaces using a light green line (#33CC33) fill with a transparency of 50% and a solid light green line (#33CC33) outline with a stroke width of 2 pixels.
+
+
+
Symbology
+
See example in section 11.2.1.
+
+
+
Minimum & maximum scales
+
None
+
+
+
Example
+
+
+
+
+
+
+
+
+
+
+
11.2.10. Styles for the layer AM.MarineRegion
+
+
+
+
+
+
+
+
Style Name
+
AM.MarineRegion.Default
+
+
+
+
+
Default Style
+
yes
+
+
+
Style Title
+
Marine Region Default Style
+
+
+
Style Abstract
+
The geometry is rendered for points as a square with a size of 6 pixels, with a blue (#85ABFF) fill and a black outline; for curves as a solid blue line (#85ABFF) with a stroke width of 2 pixels; and for surfaces using a blue (#85ABFF) fill with a transparency of 50% and a solid blue (#85ABFF) outline with a stroke width of 2 pixels.
+
+
+
Symbology
+
See example in section 11.2.1.
+
+
+
Minimum & maximum scales
+
None
+
+
+
Example
+
+
+
+
+
+
+
+
+
+
+
11.2.11. Styles for the layer AM.NitrateVulnerableZone
+
+
+
+
+
+
+
+
Style Name
+
AM.NitrateVulnerableZone.Default
+
+
+
+
+
Default Style
+
yes
+
+
+
Style Title
+
Nitrate Vulnerable Zone Default Style
+
+
+
Style Abstract
+
The geometry is rendered for points as a square with a size of 6 pixels, with a yellow (#FFFF66) fill and a black outline; for curves as a solid yellow line (#FFFF66) with a stroke width of 2 pixels; and for surfaces using a yellow (#FFFF66) fill with a transparency of 50% and a solid pale yellow (#FFFF66) outline with a stroke width of 2 pixels.
+
+
+
Symbology
+
See example in section 11.2.1.
+
+
+
Minimum & maximum scales
+
None
+
+
+
Example
+
+
+
+
+
+
+
+
+
+
+
11.2.12. Styles for the layer AM.NoiseRestrictionZone
+
+
+
+
+
+
+
+
Style Name
+
AM.NoiseRestrictionZone.Default
+
+
+
+
+
Default Style
+
yes
+
+
+
Style Title
+
Noise Restriction Zone Default Style
+
+
+
Style Abstract
+
The geometry is rendered for points as a square with a size of 6 pixels, with a mango (#FFD37F) fill and a black outline; for curves as a solid mango (#FFD37F) line with a stroke width of 2 pixels; and for surfaces using a mango (#FFD37F) fill with a transparency of 50% and a solid mango (#FFD37F) outline with a stroke width of 2 pixels.
+
+
+
Symbology
+
See example in section 11.2.1.
+
+
+
Minimum & maximum scales
+
None
+
+
+
Example
+
+
+
+
+
+
+
+
+
+
+
11.2.13. Styles for the layer AM.PlantHealthProtectionZone
+
+
+
+
+
+
+
+
Style Name
+
AM.PlantHealthProtectionZone.Default
+
+
+
+
+
Default Style
+
yes
+
+
+
Style Title
+
Plant Health Protection Zone Default Style
+
+
+
Style Abstract
+
The geometry is rendered for points as a square with a size of 6 pixels, with a red (#FF0000) fill and a black outline; for curves as a solid red (#FF0000) line with a stroke width of 2 pixels; and for surfaces using a red (#FF0000) fill with a transparency of 50% and a solid red (#FF0000) outline with a stroke width of 2 pixels.
+
+
+
Symbology
+
See example in section 11.2.1.
+
+
+
Minimum & maximum scales
+
None
+
+
+
Example
+
+
+
+
+
+
+
+
+
+
+
11.2.14. Styles for the layer AM.ProspectingAndMiningPermitArea
+
+
+
+
+
+
+
+
Style Name
+
AM.ProspectingAndMiningPermitArea.Default
+
+
+
+
+
Default Style
+
yes
+
+
+
Style Title
+
Prospecting And Mining Permit Area Default Style
+
+
+
Style Abstract
+
The geometry is rendered for points as a square with a size of 6 pixels, with a light brown (#CDAA66) fill and a black outline; for curves as a solid light brown line (#CDAA66) with a stroke width of 2 pixels; and for surfaces using a light brown (#CDAA66) fill with a transparency of 50% and a solid light brown (#CDAA66) outline with a stroke width of 2 pixels.
+
+
+
Symbology
+
See example in section 11.2.1.
+
+
+
Minimum & maximum scales
+
None
+
+
+
Example
+
+
+
+
+
+
+
+
+
+
+
11.2.15. Styles for the layer AM.RegulatedFairwayAtSeaOrLargeInlandWater
Regulated Fairway At Sea Or Large Inland Water Default Style
+
+
+
Style Abstract
+
The geometry is rendered for points as a square with a size of 6 pixels, with a blue (#85ABFF) fill and a black outline; for curves as a solid blue line (#85ABFF) with a stroke width of 2 pixels; and for surfaces using a blue (#85ABFF) fill with a transparency of 50% and a solid blue (#85ABFF) outline with a stroke width of 2 pixels.
+
+
+
Symbology
+
See example in section 11.2.1.
+
+
+
Minimum & maximum scales
+
None
+
+
+
Example
+
+
+
+
+
+
+
+
+
+
+
11.2.16. Styles for the layer AM.RestrictedZonesAroundContaminatedSites
+
+
+
+
+
+
+
+
Style Name
+
AM.RestrictedZonesAroundContaminatedSites.Default
+
+
+
+
+
Default Style
+
yes
+
+
+
Style Title
+
Restricted Zones Around Contaminated Sites Default Style
+
+
+
Style Abstract
+
The geometry is rendered for points as a square with a size of 6 pixels, with a red (#FF0000) fill and a black outline; for curves as a solid red (#FF0000) line with a stroke width of 2 pixels; and for surfaces using a red (#FF0000) fill with a transparency of 50% and a solid red (#FF0000) outline with a stroke width of 2 pixels.
+
+
+
Symbology
+
See example in section 11.2.1.
+
+
+
Minimum & maximum scales
+
None
+
+
+
Example
+
+
+
+
+
+
+
+
+
+
+
11.2.17. Styles for the layer AM.RiverBasinDistrict
+
+
+
+
+
+
+
+
Style Name
+
AM.RiverBasinDistrict.Default
+
+
+
+
+
Default Style
+
yes
+
+
+
Style Title
+
River Basin District Default Style
+
+
+
Style Abstract
+
The geometry is rendered for points as a square with a size of 6 pixels, with a lilac (#9966FF) fill and a black outline; for curves as a solid lilac line (#9966FF) with a stroke width of 2 pixels; and for surfaces using a lilac (#9966FF) fill with a transparency of 50% and a solid lilac (#9966FF) outline with a stroke width of 2 pixels.
+
+
+
Symbology
+
See example in section 11.2.1.
+
+
+
Minimum & maximum scales
+
None
+
+
+
Example
+
+
+
+
+
+
+
+
+
+
+
11.2.18. Styles for the layer AM.SensitiveArea
+
+
+
+
+
+
+
+
Style Name
+
AM.SensitiveArea.Default
+
+
+
+
+
Default Style
+
yes
+
+
+
Style Title
+
Sensitive Area Default Style
+
+
+
Style Abstract
+
The geometry is rendered for points as a square with a size of 6 pixels, with a yellow (#FFFF66) fill and a black outline; for curves as a solid yellow line (#FFFF66) with a stroke width of 2 pixels; and for surfaces using a yellow (#FFFF66) fill with a transparency of 50% and a solid pale yellow (#FFFF66) outline with a stroke width of 2 pixels.
+
+
+
Symbology
+
See example in section 11.2.1.
+
+
+
Minimum & maximum scales
+
None
+
+
+
Example
+
+
+
+
+
+
+
+
+
+
+
11.2.19. Styles for the layer AM.WaterBodyForWFD
+
+
+
+
+
+
+
+
Style Name
+
AM.WaterBodyForWFD.Default
+
+
+
+
+
Default Style
+
yes
+
+
+
Style Title
+
WFD Water Body Default Style
+
+
+
Style Abstract
+
The geometry is rendered for points as a square with a size of 6 pixels, with a light blue (#BED2FF) fill and a black outline; for curves as a solid light blue line (#BED2FF) with a stroke width of 2 pixels; and for surfaces using a light blue (#BED2FF) fill with a transparency of 50% and a solid light blue (#BED2FF) outline with a stroke width of 2 pixels.
+
+
+
Symbology
+
See example in section 11.2.1.
+
+
+
Minimum & maximum scales
+
None
+
+
+
Example
+
+
+
+
+
+
+
+
+
+
+
11.2.20. Style template for layers of additional zone types
+
+
The table below includes a template to be used for defining the default style for layers not explicitly defined in this data specification. The text in angle brackets (<…>) should be replaced with appropriate text for the layer. The rest of the "boilerplate" text should be left unchanged.
+
+
+
+
+
+
+
+
+
Style Name
+
<UpperCamelCase layer name>.Default
+
+
+
+
+
Default Style
+
yes
+
+
+
Style Title
+
<Layer title> Default Style
+
+
+
Style Abstract
+
The geometry is rendered for points as a square with a size of 6 pixels, with a <name of the colour> (#<hexadecimal colour code>) fill and a black outline; for curves as a solid <name of the colour> (#<hexadecimal colour code>) line with a stroke width of 2 pixels; and for surfaces using a <name of the colour> (#<hexadecimal colour code>) fill with a transparency of 50% and a solid <name of the colour> (#<hexadecimal colour code>) outline with a stroke width of 2 pixels.
+
+
+
Symbology
+
See example in section 11.2.1.
+
+
+
Minimum & maximum scales
+
None
+
+
+
+
+
+
+
11.3. Styles recommended to be supported by INSPIRE view services
[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: Abstract Test Suite - (normative)
+
+
+
+
+
+
+
+
Disclaimer
+
+While this Annex refers to the Commission Regulation (EU) No 1089/2010 of 23 November 2010 implementing Directive 2007/2/EC of the European Parliament and of the Council as regards interoperability of spatial data sets and services, it does not replace the legal act or any part of it.
+
+
+
+
+
The objective of the Abstract Test Suite (ATS) included in this Annex is to help the conformance testing process. It includes a set of tests to be applied on a data set to evaluate whether it fulfils the requirements included in this data specification and the corresponding parts of Commission Regulation No 1089/2010 (implementing rule as regards interoperability of spatial datasets and services, further referred to as ISDSS Regulation). This is to help data providers in declaring the conformity of a data set to the "degree of conformity, with implementing rules adopted under Article 7(1) of Directive 2007/2/EC", which is required to be provided in the data set metadata according to Commission Regulation (EC) No 2008/1205 (the Metadata Regulation).
+
+
+
Part 1 of this ATS includes tests that provide input for assessing conformity with the ISDSS regulation. In order to make visible which requirements are addressed by a specific test, references to the corresponding articles of the legal act are given. The way how the cited requirements apply to am specification is described under the testing method.
+
+
+
In addition to the requirements included in ISDSS Regulation this Technical guideline contains TG requirements too. TG requirements are technical provisions that need to be fulfilled in order to be conformant with the corresponding IR requirement when the specific technical implementation proposed in this document is used. Such requirements relate for example to the default encoding described in section 9. Part 2 of the ATS presents tests necessary for assessing the conformity with TG requirements.
+
+
+
NOTE Conformance of a data set with the TG requirement(s) included in this ATS implies conformance with the corresponding IR requirement(s).
+
+
+
The ATS is applicable to the data sets thathave been transformed to be made available through INSPIRE download services (i.e. the data returned as a response to the mandatory "Get Spatial Dataset" operation) rather than the original "source" data sets.
+
+
+
The requirements to be tested are grouped in several conformance classes. Each of these classes covers a specific aspect: one conformance class contains tests reflecting the requirements on the application schema, another on the reference systems, etc. Each conformance class is identified by a URI (uniform resource identifier) according to the following pattern:
The results of the tests should be published referring to the relevant conformance class (using its URI).
+
+
+
When an INSPIRE data specification contains more than one application schema, the requirements tested in a conformance class may differ depending on the application schema used as a target for the transformation of the data set. This will always be the case for the application schema conformance class. However, also other conformance classes could have different requirements for different application schemas. In such cases, a separate conformance class is defined for each application schema, and they are distinguished by specific URIs according to the following pattern:
An overview of the conformance classes and the associated tests is given in the table below.
+
+
+
Table 7. Overview of the tests within this Abstract Test Suite.
+
+
+
+
+
+
+
+
A.1 Application Schema Conformance Class
+
+
+
+
+
+
+
+
+
A.1.1 Schema element denomination test
+
+
+
A.1.2 Value type test
+
+
+
A.1.3 Value test
+
+
+
A.1.4 Attributes/associations completeness test
+
+
+
A.1.5 Abstract spatial object test
+
+
+
A.1.6 Constraints test
+
+
+
A.1.7 Geometry representation test
+
+
+
+
+
+
A.2 Reference Systems Conformance Class
+
+
+
+
+
+
+
+
+
A.2.1 Datum test
+
+
+
A.2.2 Coordinate reference system test
+
+
+
A.2.3 View service coordinate reference system test
+
+
+
A.2.4 Temporal reference system test
+
+
+
A.2.5 Units of measurements test
+
+
+
+
+
+
A.3 Data Consistency Conformance Class
+
+
+
+
+
+
+
+
+
A.3.1 Unique identifier persistency test
+
+
+
A.3.2 Version consistency test
+
+
+
A.3.3 Life cycle time sequence test
+
+
+
A.3.4 Validity time sequence test
+
+
+
A.3.5 Update frequency test
+
+
+
A.3.6 Geometry consistency test
+
+
+
+
+
+
A.4 Metadata IR Conformance Class
+
+
+
+
+
+
+
+
+
A.4.1 Metadata for interoperability test
+
+
+
A.4.2 Lineage metadata test
+
+
+
A.4.3 Keywords metadata test
+
+
+
+
+
+
A.5 Information Accessibility Conformance Class
+
+
+
+
+
+
+
+
+
A.5.1 Code list publication test
+
+
+
A.5.2 CRS publication test
+
+
+
A.5.3 CRS identification test
+
+
+
+
+
+
A.6 Data Delivery Conformance Class
+
+
+
+
+
+
+
+
+
A.6.1 Encoding compliance test
+
+
+
+
+
+
A.7 Portrayal Conformance Class
+
+
+
+
+
+
+
+
+
A.7.1 Layer designation test
+
+
+
+
+
+
A.8 Reporting units Conformance Class
+
+
+
+
+
+
+
+
+
A.8.1 Environmental reporting data test
+
+
+
+
+
+
A.9 Technical Guideline Conformance Class
+
+
+
+
+
+
+
+
+
A.9.1 Multiplicity test
+
+
+
A.9.2 CRS http URI test
+
+
+
A.9.3 Metadata encoding schema validation test
+
+
+
A.9.4 Metadata occurrence test
+
+
+
A.9.5 Metadata consistency test
+
+
+
A.9.6 Encoding schema validation test
+
+
+
A.9.7 Style test
+
+
+
+
+
+
+
+
In order to be conformant to a conformance class, a data set has to pass all tests defined for that conformance class.
+
+
+
In order to be conformant with the ISDSS regulation the inspected data set needs to be conformant to all conformance classes in Part 1. The conformance class for overall conformity with the ISDSS regulation is identified by the URI http://inspire.ec.europa.eu/conformance-class/ir/am/.
+
+
+
In order to be conformant with the Technical Guidelines, the dataset under inspection needs to be conformant to all conformance classes included both in Part 1 and 2. Chapter 8 describes in detail how to publish the result of testing regarding overall conformity and conformity with the conformance classes as metadata. The conformance class for overall conformity with the Technical Guidelines is identified by the URI http://inspire.ec.europa.eu/conformance-class/tg/am/3.0.
+
+
+
It should be noted that data providers are not obliged to integrate / decompose the original structure of the source data sets when they deliver them for INSPIRE. It means that a conformant dataset can contain less or more spatial object / data types than specified in the ISDSS Regulation.
+
+
+
A dataset that contains less spatial object and/or data types can be regarded conformant when the corresponding types of the source datasets after the necessary transformations fulfil the requirements set out in the ISDSS Regulation.
+
+
+
A dataset that contain more spatial object and/or data types may be regarded as conformant when
+
+
+
+
+
all the spatial object / data types that have corresponding types in the source dataset after the necessary transformations fulfil the requirements set out in the ISDSS Regulation and
+
+
+
all additional elements of the source model (spatial object types, data types, attributes, constraints and code lists together with their values) do not conflict with any rule defined in the interoperability target specifications defined for any theme within INSPIRE.
+
+
+
+
+
+
+
Open issue 1: Even though the last condition can be derived from Art. 8(4) of the Directive, the ISDSS Regulation does not contain requirements concerning the above issue. Therefore, no specific tests have been included in this abstract suite for testing conformity of extended application schemas. Annex F of the Generic Conceptual Model (D2.5) provides an example how to extend INSPIRE application schemas in a compliant way.
+
+
+
+
+
The ATS contains a detailed list of abstract tests. It should be noted that some tests in the Application schema conformance class can be automated by utilising xml schema validation tools. It should be noted that failing such validation test does not necessary reflect non-compliance to the application schema; it may be the results of erroneous encoding.
+
+
+
Each test in this suite follows the same structure:
+
+
+
+
+
Requirement: citation from the legal texts (ISDSS requirements) or the Technical Guidelines (TG requirements);
+
+
+
Purpose: definition of the scope of the test;
+
+
+
Reference: link to any material that may be useful during the test;
+
+
+
Test method: description of the testing procedure.
+
+
+
+
+
According to ISO 19105:2000 all tests in this ATS are basic tests. Therefore, this statement is not repeated each time.
+
+
+
Part 1 - (normative)
+
+
Conformity of Management Restriction and Regulation Zones data with Commission Regulation No 1089/2010
+
+
+
This part contains conformance classes and tests for checking the requirements related to Area Management Restriction and Regulation Zones, as defined in Annex IV of the Implementing Rules, with the exception of Section 11.4.2.
+
+
+
NOTE 1 The requirement in point 1 of Section 11.4.2 makes reference to the "requirements of their respective INSPIRE spatial data theme(s)". Therefore, no tests related to this requirement are included. Data providers should simply check conformance against the ATS for the relevant spatial data theme(s).
+
+
+
NOTE 2 The subject of requirement in Section 11.4.2, point 2 of Annex IV of the Implementing Rules is "environmental reporting data". Therefore, a separate conformance class is defined for the purpose of checking compliance of environmental reporting data with this requirement. It is not necessary for Area Management Restriction and Regulation Zones data to pass this conformance class in order to claim compliance with the Implementing Rules.
Purpose: Verification whether each element of the dataset under inspection carries a name specified in the target application schema(s).
+
+
+
Reference: Art. 3 and Art.4 of Commission Regulation No 1089/2010
+
+
+
Test Method: Examine whether the corresponding elements of the source schema (spatial object types, data types, attributes, association roles and code lists) are mapped to the target schema with the correct designation of mnemonic names.
+
+
+
+
+
NOTE Further technical information is in the Feature catalogue and UML diagram of the application schema(s) in section 5.2.
+
+
+
+
A.1.2. Value type test
+
+
+
+
Purpose: Verification whether all attributes or association roles use the corresponding value types specified in the application schema(s).
+
+
+
Reference: Art. 3, Art.4, Art.6(1), Art.6(4), Art.6(5) and Art.9(1)of Commission Regulation No 1089/2010.
+
+
+
Test Method: Examine whether the value type of each provided attribute or association role adheres to the corresponding value type specified in the target specification.
+
+
+
+
+
NOTE 1 This test comprises testing the value types of INSPIRE identifiers, the value types of attributes and association roles that should be taken from code lists, and the coverage domains.
+
+
+
NOTE 2 Further technical information is in the Feature catalogue and UML diagram of the application schema(s) in section 5.2.
+
+
+
+
A.1.3. Value test
+
+
+
+
Purpose: Verify whether all attributes or association roles whose value type is a code list take the values set out therein.
+
+
+
Reference: Art.4 (3) of Commission Regulation No 1089/2010.
+
+
+
Test Method: When an attribute / association role has a code list as its type, compare the values of each instance with those provided in the application schema. To pass this tests any instance of an attribute / association role
+
+
+
+
shall take only values explicitly specified in the code list when the code list’s extensibility is "none" (EnvironmentalDomain).
+
+
+
+
+
+
+
+
NOTE 1 This test is not applicable to code lists with extensibility "open" or "any".
+
+
+
NOTE 2 When a data provider only uses code lists with narrower (more specific values) this test can be fully performed based on internal information.
+
+
+
+
A.1.4. Attributes/associations completeness test
+
+
+
+
Purpose: Verification whether each instance of spatial object type and data types include all attributes and association roles as defined in the target application schema.
+
+
+
Reference: Art. 3, Art.4(1), Art.4(2), and Art.5(2) of Commission Regulation No 1089/2010.
+
+
+
Test Method: Examine whether all attributes and association roles defined for a spatial object type or data type are present for each instance in the dataset.
+
+
+
+
+
NOTE 1 Further technical information is in the Feature catalogue and UML diagram of the application schema(s) in section 5.2.
+
+
+
NOTE 2 If an attribute has the stereotype «voidable», then according to the INSPIRE Generic Conceptual Model (section 9.4.5), it shall be possible to qualify a value of void in the data with one of the three "void reason" values "unknown", "unpopulated" or "withheld".
+
+
+
NOTE 3 If the characteristic described by the attribute or association role does not exist in or apply to the real world entity, the attribute or association role does not need to be present in the data set.
+
+
+
+
A.1.5. Abstract spatial object test
+
+
+
+
Purpose: Verification whether the dataset does NOT contain abstract spatial object / data types defined in the target application schema(s).
+
+
+
Reference: Art.5(3) of Commission Regulation No 1089/2010
+
+
+
Test Method: Examine that there are NO instances of abstract spatial object / data types in the dataset provided.
+
+
+
+
+
NOTE Further technical information is in the Feature catalogue and UML diagram of the application schema(s) in section 5.2.
+
+
+
+
A.1.6. Constraints test
+
+
+
+
Purpose: Verification whether the instances of spatial object and/or data types provided in the dataset adhere to the constraints specified in the target application schema(s).
+
+
+
Reference: Art. 3, Art.4(1), and Art.4(2) of Commission Regulation No 1089/2010.
+
+
+
Test Method: Examine all instances of data for the constraints specified for the corresponding spatial object / data type. Each instance shall adhere to all constraints specified in the target application schema(s).
+
+
+
+
+
NOTE Further technical information is in the Feature catalogue and UML diagram of the application schema(s) in section 5.2.
+
+
+
+
A.1.7. Geometry representation test
+
+
+
+
Purpose: Verification whether the value domain of spatial properties is restricted as specified in the Commission Regulation No 1089/2010.
+
+
+
Reference: Art.12(1) of Commission Regulation No 1089/2010
+
+
+
Test Method: Check whether all spatial properties only use 0, 1 and 2-dimensional geometric objects that exist in the right 2-, 3- or 4-dimensional coordinate space, and where all curve interpolations respect the rules specified in the reference documents.
+
+
+
+
+
NOTE Further technical information is in OGC Simple Feature spatial schema v1.2.1 [06-103r4].
Purpose: Verify whether each instance of a spatial object type is given with reference to one of the (geodetic) datums specified in the target specification.
+
+
+
Reference: Annex II Section 1.2 of Commission Regulation No 1089/2010
+
+
+
Test Method: Check whether each instance of a spatial object type specified in the application schema(s) in section 5 has been expressed using:
+
+
+
+
the European Terrestrial Reference System 1989 (ETRS89) within its geographical scope; or
+
+
+
the International Terrestrial Reference System (ITRS) for areas beyond the ETRS89 geographical scope; or
+
+
+
other geodetic coordinate reference systems compliant with the ITRS. Compliant with the ITRS means that the system definition is based on the definition of ITRS and there is a well-established and described relationship between both systems, according to the EN ISO 19111.
+
+
+
+
+
+
+
+
NOTE Further technical information is given in Section 6 of this document.
+
+
+
+
A.2.2. Coordinate reference system test
+
+
+
+
Purpose: Verify whether the two- and three-dimensional coordinate reference systems are used as defined in section 6.
+
+
+
Reference: Section 6 of Commission Regulation 1089/2010.
+
+
+
Test Method: Inspect whether the horizontal and vertical components of coordinates one of the corresponding coordinate reference system has been:
+
+
+
+
Three-dimensional Cartesian coordinates based on a datum specified in 1.2 and using the parameters of the Geodetic Reference System 1980 (GRS80) ellipsoid.
+
+
+
Three-dimensional geodetic coordinates (latitude, longitude and ellipsoidal height) based on a datum specified in 1.2 and using the parameters of the GRS80 ellipsoid.
+
+
+
Two-dimensional geodetic coordinates (latitude and longitude) based on a datum specified in 1.2 and using the parameters of the GRS80 ellipsoid.
+
+
+
Plane coordinates using the ETRS89 Lambert Azimuthal Equal Area coordinate reference system.
+
+
+
Plane coordinates using the ETRS89 Lambert Conformal Conic coordinate reference system.
+
+
+
Plane coordinates using the ETRS89 Transverse Mercator coordinate reference system.
+
+
+
For the vertical component on land, the European Vertical Reference System (EVRS) shall be used to express gravity-related heights within its geographical scope. Other vertical reference systems related to the Earth gravity field shall be used to express gravity-related heights in areas that are outside the geographical scope of EVRS.
+
+
+
For the vertical component in marine areas where there is an appreciable tidal range (tidal waters), the Lowest Astronomical Tide (LAT) shall be used as the reference surface.
+
+
+
For the vertical component in marine areas without an appreciable tidal range, in open oceans and effectively in waters that are deeper than 200 meters, the Mean Sea Level (MSL) or a well-defined reference level close to the MSL shall be used as the reference surface."
+
+
+
For the vertical component in the free atmosphere, barometric pressure, converted to height using ISO 2533:1975 International Standard Atmosphere, or other linear or parametric reference systems shall be used. Where other parametric reference systems are used, these shall be described in an accessible reference using EN ISO 19111-2:2012.
+
+
+
+
+
+
+
+
NOTE Further technical information is given in Section 6 of this document.
+
+
+
+
A.2.3. View service coordinate reference system test
+
+
+
+
Purpose: Verify whether the spatial data set is available in the two dimensional geodetic coordinate system for their display with the INSPIRE View Service.
+
+
+
Reference: Annex II Section 1.4 of Commission Regulation 1089/2010
+
+
+
Test Method: Check that each instance of a spatial object types specified in the application schema(s) in section 5 is available in the two-dimensional geodetic coordinate system
+
+
+
+
+
NOTE Further technical information is given in Section 6 of this document.
+
+
+
+
A.2.4. Temporal reference system test
+
+
+
+
Purpose: Verify whether date and time values are given as specified in Commission Regulation No 1089/2010.
+
+
+
Reference: Art.11(1) of Commission Regulation 1089/2010
+
+
+
Test Method: Check whether:
+
+
+
+
the Gregorian calendar is used as a reference system for date values;
+
+
+
the Universal Time Coordinated (UTC) or the local time including the time zone as an offset from UTC are used as a reference system for time values.
+
+
+
+
+
+
+
+
NOTE Further technical information is given in Section 6 of this document.
+
+
+
+
A.2.5. Units of measurements test
+
+
+
+
Purpose: Verify whether all measurements are expressed as specified in Commission Regulation No 1089/2010.
+
+
+
Reference: Art.12(2) of Commission Regulation 1089/2010
+
+
+
Test Method: Check whether all measurements are expressed in SI units or non-SI units accepted for use with the International System of Units.
+
+
+
+
+
NOTE 1 Further technical information is given in ISO 80000-1:2009.
+
+
+
NOTE 2 Degrees, minutes and seconds are non-SI units accepted for use with the International System of Units for expressing measurements of angles.
Purpose: Verify whether the namespace and localId attributes of the external object identifier remain the same for different versions of a spatial object.
+
+
+
Reference: Art. 9 of Commission Regulation 1089/2010.
+
+
+
Test Method: Compare the namespace and localId attributes of the external object identifiers in the previous version(s) of the dataset with the namespace and localId attributes of the external object identifiers of current version for the same instances of spatial object / data types; To pass the test, neither the namespace, nor the localId shall be changed during the life-cycle of a spatial object.
+
+
+
+
+
NOTE 1 This test can be performed exclusively on the basis of the information available in the database of the data providers.
+
+
+
NOTE 2 When using URI this test includes the verification whether no part of the construct has been changed during the life cycle of the instances of spatial object / data types.
+
+
+
NOTE 3 Further technical information is given in section 14.2 of the INSPIRE Generic Conceptual Model.
+
+
+
+
A.3.2. Version consistency test
+
+
+
+
Purpose: Verify whether different versions of the same spatial object / data type instance belong to the same type.
+
+
+
Reference: Art. 9 of Commission Regulation 1089/2010.
+
+
+
Test Method: Compare the types of different versions for each instance of spatial object / data type
+
+
+
+
+
NOTE 1 This test can be performed exclusively on the basis of the information available in the database of the data providers.
+
+
+
+
A.3.3. Life cycle time sequence test
+
+
+
+
Purpose: Verification whether the value of the attribute beginLifespanVersion refers to an earlier moment of time than the value of the attribute endLifespanVersion for every spatial object / object type where this property is specified.
+
+
+
Reference: Art.10(3) of Commission Regulation 1089/2010.
+
+
+
Test Method: Compare the value of the attribute beginLifespanVersion with attribute endLifespanVersion. The test is passed when the beginLifespanVersion value is before endLifespanVersion value for each instance of all spatial object/data types for which this attribute has been defined.
+
+
+
+
+
NOTE 1 This test can be performed exclusively on the basis of the information available in the database of the data providers.
+
+
+
+
A.3.4. Validity time sequence test
+
+
+
+
Purpose: Verification whether the value of the attribute validFrom refers to an earlier moment of time than the value of the attribute validTo for every spatial object / object type where this property is specified.
+
+
+
Reference: Art.12(3) of Commission Regulation 1089/2010.
+
+
+
Test Method: Compare the value of the attribute validFrom with attribute validTo. The test is passed when the validFrom value is before validTo value for each instance of all spatial object/data types for which this attribute has been defined.
+
+
+
+
+
NOTE 1 This test can be performed exclusively on the basis of the information available in the database of the data providers.
+
+
+
+
A.3.5. Update frequency test
+
+
+
+
Purpose: Verify whether all the updates in the source dataset(s) have been transmitted to the dataset(s) which can be retrieved for the AM data theme using INSPIRE download services.
+
+
+
Reference: Art.8 (2) of Commission Regulation 1089/2010.
+
+
+
Test Method: Compare the values of beginning of life cycle information in the source and the target datasets for each instance of corresponding spatial object / object types. The test is passed when the difference between the corresponding values is less than 6 months.
+
+
+
+
+
NOTE 1 This test can be performed exclusively on the basis of the information available in the database of the data providers.
+
+
+
+
A.3.6. Geometry consistency test
+
+
+
+
Purpose: Verify whether in all cases, where the geometry of a spatial object is derived from another spatial object, the geometries of the two objects are consistent.
+
+
+
Reference: Annex IV, section 11.4.1, point (1) of Commission Regulation 1089/2010.
+
+
+
Test Method: For all objects in an AM data set, whose geometry has been derived from another spatial object, compare the geometries of the two objects. The test is passed when the geometries are consistent.
+
+
+
+
+
NOTE 1 This test can be performed only on the basis of the information available in the databases of the data providers of the AM objects and the source objects from which the geometries have been derived.
Purpose: Verify whether the metadata for interoperability of spatial data sets and services described in 1089/2010 Commission Regulation have been created and published for each dataset related to the AM data theme.
+
+
+
Reference: Art.13 of Commission Regulation 1089/2010
+
+
+
Test Method: Inspect whether metadata describing the coordinate reference systems, encoding, and spatial representation type have been created and published. If the spatial data set contains temporal information that does not refer to the default temporal reference system, inspect whether metadata describing the temporal reference system have been created and published. If an encoding is used that is not based on UTF-8, inspect whether metadata describing the character encoding have been created.
+
+
+
+
+
NOTE Further technical information is given in section 8 of this document.
+
+
+
+
A.4.2. Lineage metadata test
+
+
+
+
Purpose: Verify whether in all cases, where geometries of the spatial objects in a ManagementRestrictionOrRegulationZone data set are derived from the geometries of spatial objects in another data set, the source data set (including its version) is described as part of the lineage metadata element
+
+
+
Reference: Annex IV, section 11.4.1, point (2) of Commission Regulation 1089/2010.
+
+
+
Test Method: For all ManagementRestrictionOrRegulationZone data sets, in which geometries of the spatial objects have been derived from the geometries of spatial objects in another data set, inspect whether the lineage metadata element contains a description of the source data set (including its version).
+
+
+
+
+
NOTE 1 Whether this test needs to be performed depends on information available only to the data providers of the ManagementRestrictionOrRegulationZone data set (i.e. whether the geometries of the spatial objects in the data set are derived from the geometries of spatial objects in another data set).
+
+
+
+
A.4.3. Keywords metadata test
+
+
+
+
Purpose: Verify whether keywords metadata element contains (a) one or several keywords describing the high-level classification of the zone type(s) included in the data set, as defined in ZoneTypeCode code list, and (b) one or several keywords describing the official document number(s) of the legal instrument(s) under which the zone(s) included in the data set is (are) established. Verify whether for Union legislation, the CELEX number is used.
+
+
+
Reference: Annex IV, section 11.4.1, point (3) of Commission Regulation 1089/2010.
+
+
+
Test Method: Inspect whether the keywords metadata element contains one or several keywords describing the high-level classification of the zone type(s) included in the data set. Check whether the values describing the zone type(s) are taken from the ZoneTypeCode code list. Inspect whether the keywords metadata element contains one or several keywords describing the official document number(s) of the legal instrument(s) under which the zone(s) included in the data set is (are) established. Check whether for Union legislation, the CELEX number is used.
Purpose: Verify whether all additional values used in the data sets for attributes, for which narrower values or any other value than specified in Commission Regulation 1089/2010 are allowed, are published in a register.
+
+
+
Reference: Art.6(3) and Annex IV Section 11.3
+
+
+
Test Method: For each additional value used in the data sets for code list-valued attributes, check whether it is published in a register.
+
+
+
+
+
NOTE Further technical information is given in section 5 of this document.
+
+
+
+
A.5.2. CRS publication test
+
+
+
+
Purpose: Verify whether the identifiers and the parameters of coordinate reference system are published in common registers.
+
+
+
Reference: Annex II Section 1.5
+
+
+
Test Method: Check whether the identifier and the parameter of the CRS used for the dataset are included in a register.
+
+
+
+
+
NOTE Further technical information is given in section 6 of this document.
+
+
+
+
A.5.3. CRS identification test
+
+
+
+
Purpose: Verify whether identifiers for other coordinate reference systems than specified in Commission Regulation 1089/2010 have been created and their parameters have been described according to EN ISO 19111 and ISO 19127.
+
+
+
Reference: Annex II Section 1.3.4
+
+
+
Test Method: Check whether the register with the identifiers of the coordinate reference systems is accessible.
+
+
+
+
+
NOTE Further technical information is given in section 6 of this document.
Purpose: Verify whether each spatial object type has been assigned to the layer designated according to Commission Regulation 1089/2010.
+
+
+
Reference: Art. 14(1), Art. 14(2) and Annex IV Section 11.5 .
+
+
+
Test Method: Check whether data is made available for the view network service using the specified layers respectively. Check whether one layer following the template AM.<CodeListValue> (e.g. AM.AirQualityManagementZone for the zone type airQualityManagementZone) is provided for each zone type used in the data set.
+
+
+
+
+
NOTE Further technical information is given in section 11 of this document.
+
+
+
Part 2 - (normative)
+
+
Conformity of environmental reporting data with Commission Regulation No 1089/2010
+
+
+
This part contains a conformance class and test for checking the requirements related to reporting units (see Section 11.4.2 of Annex IV of the Implementing Rules).
+
+
+
NOTE 1 The requirement in point 1 of Section 11.4.2 makes reference to the "requirements of their respective INSPIRE spatial data theme(s)". Therefore, no tests related to this requirement are included. Data providers should simply check conformance against the ATS for the relevant spatial data theme(s).
+
+
+
NOTE 2 The subject of requirement in Section 11.4.2, point 2 of Annex IV of the Implementing Rules is "environmental reporting data". Therefore, a separate conformance class is defined for the purpose of checking compliance of environmental reporting data with this requirement. It is not necessary for Area Management Restriction and Regulation Zones data to pass this conformance class in order to claim compliance with the Implementing Rules.
Purpose: Verify whether environmental reporting data includes an explicit reference to INSPIRE spatial objects, where, to establish a spatial reference, this reporting data refers to real-world entities that are made available as spatial objects in accordance with Commission Regulation No 1089/2010.
+
+
+
Reference: Annex IV, Section 11.4.2, point 2.
+
+
+
Test Method: Check whether the environmental reporting data contains some kind of reference to INSPIRE spatial objects (e.g. using the inspireId), where it refers to the corresponding real-world entities to establish a spatial reference.
+
+
+
+
+
Part 2 - (informative)
+
+
Conformity with the technical guideline (TG) Requirements
Purpose: Verify whether each instance of an attribute or association role specified in the application schema(s) does not include fewer or more occurrences than specified in section 5.
+
+
+
Reference: Feature catalogue and UML diagram of the application schema(s) in section 5 of this guideline.
+
+
+
Test Method: Examine that the number of occurrences of each attribute and/or association role for each instance of a spatial object type or data type provided in the dataset corresponds to the number of occurrences of the attribute / association role that is specified in the application schema(s) in section 5.
+
+
+
+
+
+
A.9.2. CRS http URI test
+
+
+
+
Purpose: Verify whether the coordinate reference system used to deliver data for INSPIRE network services has been identified by URIs according to the EPSG register.
+
+
+
Reference: Section 6 of this technical guideline
+
+
+
Test Method: Compare the URI of the dataset with the URIs in the table.
+
+
+
+
+
NOTE 1 Passing this test implies the fulfilment of test A6.2
Purpose: Verify whether the metadata follows an XML schema specified in ISO/TS 19139.
+
+
+
Reference: Section 8 of this technical guideline, ISO/TS 19139
+
+
+
Test Method: Inspect whether provided XML schema is conformant to the encoding specified in ISO 19139 for each metadata instance.
+
+
+
+
+
NOTE 1 Section 2.1.2 of the Metadata Technical Guidelines discusses the different ISO 19139 XML schemas that are currently available.
+
+
+
+
A.9.4. Metadata occurrence test
+
+
+
+
Purpose: Verify whether the occurrence of each metadata element corresponds to those specified in section 8.
+
+
+
Reference: Section 8 of this technical guideline
+
+
+
Test Method: Examine the number of occurrences for each metadata element. The number of occurrences shall be compared with its occurrence specified in Section 8:
+
+
+
+
+
NOTE 1 Section 2.1.2 of the Metadata Technical Guidelines discusses the different ISO 19139 XML schema
+
+
+
+
A.9.5. Metadata consistency test
+
+
+
+
Purpose: Verify whether the metadata elements follow the path specified in ISO/TS 19139.
+
+
+
Reference: Section 8 of this technical guideline, ISO/TS 19139
+
+
+
Test Method: Compare the XML schema of each metadata element with the path provide in ISO/TS 19137.
+
+
+
+
+
NOTE 1 This test does not apply to the metadata elements that are not included in ISO/TS 19139.
+
+
+
+
A.9.6. Encoding schema validation test
+
+
+
+
Purpose: Verify whether the provided dataset follows the rules of default encoding specified in section 9 of this document
+
+
+
Reference: section 9 of this technical guideline
+
+
+
Test Method: Inspect whether provided encoding(s) is conformant to the encoding(s) for the relevant application schema(s) as defined in section 9:
+
+
+
+
+
NOTE 1 Applying this test to the default encoding schema described in section 9 facilitates testing conformity with the application schema specified in section 5. In such cases running this test with positive result may replace tests from A1.1 to A1.4 provided in this abstract test suite.
+
+
+
NOTE 2 Using Schematron or other schema validation tool may significantly improve the validation process, because some some complex constraints of the schema cannot be validated using the simple XSD validation process. On the contrary to XSDs Schematron rules are not delivered together with the INSPIRE data specifications. Automating the process of validation (e.g. creation of Schematron rules) is therefore a task and an opportunity for data providers.
+
+
+
+
A.9.7. Style test
+
+
+
+
Purpose: Verify whether the styles defined in section 11.2 have been made available for each specified layer.
+
+
+
Reference: section 11.2.
+
+
+
Test Method: Check whether the styles defined in section 11.2 have been made available for each specified layer.
+
+
+
+
+
+
+
+
+
+
Annex B: Use cases - (informative)
+
+
+
This annex describes some use cases that were used as a basis for the development of this data specification. The use-cases which are described here are supported through the information included in the high-level data specification. For each use-case there is a high-level description outlining the requirements as well as specific examples and illustrations to better explain data relationships in the AM specification and thus facilitate the comprehension and implementation of the data model.
+
+
+
B.1. Finding regulation, management and reporting area by location
+
+
+
+
+
+
+
+
Use Case Description
+
+
+
Name
+
Planning new management rules for water quality control
+
+
+
Primary actor
+
Spatial Planner
+
+
+
Goal
+
To introduce new restrictions and rules for river systems to protect / improve water quality by determining that they will be in line with rules which are already active in the area of interest or that they will not conflict with any valid regulation.
+
+
+
System under
+consideration
+
Water Quality Control System (operated by a municipal authority of hydraulic works)
+
+
+
Importance
+
High
+
+
+
Description
+
The spatial planner performs a spatial overlay analysis using the planning area of interest to select all features from AM datasets which are completely within, intersects, or are within a buffer of a certain distance.
+
+
+
Pre-condition
+
The spatial data for the planning area has been obtained / generated as a polygon coverage, as boundary lines for defining the extent, or defined as a buffer distance from the spatial object of interest (e.g. river branch). Data on protected areas (e.g. Natura2000) (according to the Protected Sites data specification) and on land use (according to the Land Use data specification) has been obtained from the relevant INSPIRE download services or adapted from local data sources.
+
+
+
Post-condition
+
Spatial data set obtained through an overlay analysis of the reservoir protection zone, mine buffer zone, Natura2000 protection sites and the planning area of interest, in company with attribute data (e.g. date protection started) about valid rules, regulations, or other legislative references acting in the area.
+
+
+
Flow of Events – Basic Path
+
+
+
Step 1
+
The spatial planner defines the spatial boundaries of the planning area.
+
+
+
Step 2
+
The spatial planner uses a desktop GIS application to connect to the INSPIRE Geo-portal catalogue service and adds all AM datasets and other datasets (PS, LU datasets, for example) onto the map of the planning region through a download service using the Web Feature Server protocol.
+
+
+
Step 3
+
Having included all data sources in the map, the spatial planner now performs a spatial overlay analysis using the planning area of interest to select all features from AM datasets which are completely within, intersects, or are within a buffer of a certain distance.
+
+
+
Step 4
+
In order to observe the regulation, management and reporting areas in the local spatial plan, the planner interprets the spatial metadata associated with the features to determine the accuracy of the delineation and whether they are absolute or if they need to be further detailed and formalized through the local spatial plan.
+
+
+
Step 5
+
The spatial planner computes the relative shares of regulated / managed / restricted areas inside the planning area (as well as similar spatial information for existing land use types) to figure out relative importance of different management and reporting regimes associated with the legally-managed areas and continuous impacts of different practices particularly applied by dominant land uses.
+
+
+
Step 6
+
The query provides the planner with the names of all regulations (laws, protocols and legally binding agreements) which are valid for each area in the result set. Furthermore, it allows learning which authority on which administrative level is responsible for managing the regulation and any associated reporting regimes which may be established for them. It is also possible to capture necessary contact information for the relevant authorities in order to obtain more detailed information.
+
+
+
Step 7
+
As it may be important in some cases to compare previous rules which are no longer active in the region with currently valid ones, the planner may also need to know which areas are historical and which are currently active. This information is visible from the attributes stating the start and end dates for the regulation itself and any associated management or reporting regime.
+
+
+
Flow of Events – Alternative Paths
+
+
+
+
NONE
+
+
+
Data set: Planning area extent
+
+
+
Description
+
Planning area coverage showing the spatial boundaries of the planning area.
+
+
+
Type
+
input
+
+
+
Data provider
+
National/sub-national authority of hydraulic works (hwa)
+
+
+
Geographic scope
+
Country C1
+
+
+
Thematic scope
+
Planning area extent. Available as a polygon coverage or as boundary lines for defining the extent, or spatially generated as a buffer polygon around the spatial object of interest based on the defined buffer distance.
Mining Permit Area Y and buffer zone to address safety, aesthetic-disturbance, environmental, and cultural issues/impacts due to mining operations in Mining Site Y.
+
+
+
Type
+
input
+
+
+
Data provider
+
Ministry of Energy and Natural Resources of Country C1 (Data available through the INSPIRE Geo-portal).
Corine Land Cover (CLC) types for Europe (as proxy to land use information).
+
+
+
Corine Land Cover 2006 seamless vector data - version 13 (02/2010)
+
+
+
Corine Land Cover 2006 raster data - version 13 (02/2010)
+
+
+
Corine Land Cover 2000 seamless vector data - version 13 (02/2010)
+
+
+
Corine Land Cover 2000 raster data - version 13 (02/2010)
+
+
+
+
Type
+
input
+
+
+
Data provider
+
European Environment Agency (EEA)
+
+
+
Geographic scope
+
+
CLC2000: EU27, Albania, Bosnia and Herzegovina, Croatia, Liechtenstein, Macedonia, the former Yugoslavian Republic of, Montenegro, Norway, Serbia, Turkey
+
+
+
CLC2006: EU27, Albania, Bosnia and Herzegovina, Croatia, Iceland, Liechtenstein, Macedonia, the former Yugoslavian Republic of, Montenegro, Norway, Serbia, Turkey
Figure B1.1 – (a) Example UML use case diagram; (b) Sample use case data flow diagram
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
(a)
+
(b)
+
(c)
+
+
+
+
+
Figure B1.2 – (a) Natura2000 sites, (b) Reservoir protection zones, (c) mining site and mine-specific buffer zone overlapping the sample planning area
+
+
+
+
B.2. Finding location of regulation, management or reporting area by identifier or name
+
+
+
+
+
+
+
+
Use Case Description
+
+
+
+
+
Name
+
Performing searches for regulation, management and reporting areas by name or identifier.
+
+
+
Primary actor
+
Analyst
+
+
+
Goal
+
Identifying the location of individual areas across the territory of Europe and better interpreting and contextualizing the qualitative information contained within a report.
+
+
+
System under
+consideration*
+
Wildlife Observation System (operated by an environmental sciences research institute)
+
+
+
Importance
+
Medium
+
+
+
Description
+
An analyst working for an environmental sciences research institute has received a report containing qualitative information about a number of reporting areas across the territory of Europe. Along with the report came a DVD with tabular data associated with different reporting areas. In the report, the reporting areas are identified as a mix between formal unique identifiers and popular names – in the accompanying tabular datasets, all records are associated with formal unique identifiers.
+
+
+
Pre-condition
+
The report received/produced by the research institute contains tabular information including or images showing the name of the area of interest and/or the unique official identifier assigned to the area.
+
+
+
Post-condition
+
+
+
+
Flow of Events – Basic Path
+
+
+
Step 1
+
The analyst retrieves PS data (nature conservation zones) from the INSPIRE Geo-portal’s download services.
+
+
+
Step 2
+
The analyst performs tabular searches for regulation, management and reporting areas (nature conservation zones) by name or identifier.
+
+
+
Step 3
+
The analyst retrieves AM data (river basin districts) from the INSPIRE Geo-portal’s download services.
+
+
+
Step 4
+
The analyst performs spatial queries for regulation, management and reporting areas (selected nature conservation zones and corresponding river basin districts).
+
+
+
Step 5
+
The analyst retrieves HY data (hydrographical features) from the INSPIRE Geo-portal’s download services or contacts the management authority of the relevant river basin district to collect information about hydrographical features in the proximity of her/his site(s) of interest.
+
+
+
Step 6
+
In order to perform some further studies, the analyst would like to execute a correlation query between the data contained in a report and a number of case study sites. In order to achieve this, she/he adds the data from the report DVD to his desktop GIS application and "joins" the tabular data to the AM datasets using the areas unique identifier as a key.
+
+
+
Step 7
+
The analyst is now able to create geo-statistical visualizations, e.g. showing report values as graded colours on a map. She/he is also able to perform correlation analysis between her/his case study sites and the geocoded reporting data.
+
+
+
Flow of Events – Alternative Paths
+
+
+
+
NONE
+
+
+
Data set: Natura2000 sites
+
+
+
Description
+
Natura 2000 data - the European network of protected sites.
+
+
+
Data provider
+
EEA, National Authority of Protected Sites (in accordance with the "Protected Sites" data specification, available from the relevant INSPIRE download service, EEA data centre or national data sources).
Spatial extent of river basin districts in Europe.
+
+
+
Type
+
input
+
+
+
Data provider
+
European Environment Agency (EEA) (Data available directly from WISE – Water Information System for Europe or via the INSPIRE Geo-portal’s download services).
Figure B2.1 – (a) Example UML use case diagram; (b) Sample use case data flow diagram
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
(a)
+
(b)
+
(c)
+
+
+
+
+
Figure B2.2 – (a) Reporting information with site code, (b) site location within the Natura2000 network, and (c) river basin district containing the site of interest
+
+
+
+
B.3. Finding regulation, management or reporting areas by regulation
+
+
+
+
+
+
+
+
Use Case Description
+
+
+
+
+
Name
+
Locating regulation, management or reporting areas mentioned in a legal/official document.
+
+
+
Primary actor
+
Analyst, Contractor
+
+
+
Goal
+
Identifying areas which are covered by certain laws or regulations and assessing corresponding implications.
+
+
+
System under
+consideration*
+
Construction Auditing System (operated by the Ministry of Public Works of Country C3).
+
+
+
Importance
+
High
+
+
+
Description
+
An analyst from a central authority has the task of planning construction and performing an EIA for a port area project. From the relevant obligations, she/he basically knows about the rules and measures for protecting bathing water quality, but is not sure about the name of the coastal water authoritieswho will co-approve the construction permits, and their responsibility areas. The contractor, on the other hand, needs to organize a list of the quality stations from which he would need to report information to the administration during the entire construction period as explicitly stated in the tender specification. For this specific purpose, they will need to perform a spatial query to learn about the coastal authorities responsible for activities in the coastal water area and then an overlay operation to get the list of stations from which they will collect/report the periodical data.
+
+
+
Pre-condition
+
The analyst has necessary geo-referenced drawings or spatial layers of the project area, which will also be provided to the contractor winning the tender.
+
+
+
Post-condition
+
Bathing water quality stations as part of the port area project are addressed as well as the competent authorities.
+
+
+
Flow of Events – Basic Path
+
+
+
Step 1
+
By using the geographic extent of the project area (obtained from local data repositories) and the layer of WISE coastal waters (accessed through INSPIRE Geo-portal), the analyst performs a spatial overlay operation to identify coastal water regions under potential impact of the project and relevant bathing water authorities.
+
+
+
Step 2
+
The analyst determines the reporting obligations specifically asked by coastal water authorities and places them in the tender specifications as special conditions.
+
+
+
Step 3
+
The contractor collects the project area extent from the authority and the spatial layer of bathing water stations through the INSPIRE Geo-portals data access and download services.
+
+
+
Step 4
+
The contractor performs an overlay operation to select a list of quality stations (based on their locations) from which she/he will need to compile data and fulfil reporting requirements asked in the tender specifications document.
+
+
+
Flow of Events – Alternative Paths
+
+
+
+
NONE
+
+
+
Data set: Project area coverage
+
+
+
Description
+
Spatial boundaries of the construction site for the port construction project.
+
+
+
Data provider
+
Ministry of Public Works of Country C3 (Analyst’s organization)
+
+
+
Type
+
input
+
+
+
Geographic scope
+
Port project area (CAD drawings, GIS layer, etc.).
+
+
+
Thematic scope
+
As part of planning for port construction project.
+
+
+
Scale, resolution
+
1:1.000
+
+
+
Delivery
+
For official use only
+
+
+
Documentation
+
Provided in annexes of the tender specification document.
+
+
+
Data set: WISE coastal waters
+
+
+
Description
+
Coastal waters are defined as one nautical mile from the coastline and extending, where appropriate, up to the outer limit of transitional waters. Coastal waters are included in RBDs, but this is not consistently reported by Member States.
+
+
+
Type
+
input
+
+
+
Data provider
+
National authorities in Member States, European Environment Agency (EEA) (Data available directly from WISE – Water Information System for Europe or via the INSPIRE Geo-portal’s download services).
+
+
+
Geographic scope
+
EU27, Norway, Switzerland
+
+
+
Thematic scope
+
River basin districts are defined as the area of land and sea, made up of one or more neighbouring river basins together with their associated groundwaters and coastal waters, which is identified under Article 3(1) as the main unit for management of river basins.
Bathing water stations dataset presents the latest information as reported by the Member States (EU27) for the 2009 bathing season, as well as some historical data since 1990.
+
+
+
Data provider
+
National responsible authorities of Member States, European Environment Agency (EEA).
+
+
+
Type
+
input
+
+
+
Geographic scope
+
EU27, Croatia, Switzerland
+
+
+
Thematic scope
+
The EU Bathing Waters Directive 76/160/EEC requires Member States to identify popular bathing places in fresh and coastal waters and monitor them for indicators of microbiological pollution (and other substances) throughout the bathing season which runs from May to September.
Performing an assessment on spatial objects dynamically changing due to their nature and/or questioning previous versions of spatial information.
+
+
+
Primary actor
+
Researcher
+
+
+
Goal
+
Generating temporal statistics. Temporal variability of spatial information may also need to be considered in the AM data model as the historical information on the managed, regulated, restricted and/or reported areas becomes more important in some cases for performing time-span (or periodical) assessments or settling disputes that may arise due to changes in an area. Such changes may result from timely-varying orientations in administrative definitions or legislation or from the dynamic nature of the phenomenon itself that characterizes the area (e.g. land cover). Any change in time could change the borders of the area or just the nature of restriction (through different restriction rules and preventive measures).
+
+
+
System under
+consideration
+
Not available
+
+
+
Importance
+
High
+
+
+
Description
+
A researcher performing a graduate study on integrated coastal zone management needs to integrate data on urban morphological zones (UMZs) into her/his analyses. However, she/he is only interested in the spatial statistics and observed changes within an inside buffer of 10 km from the coastline. For performing such an assessment, she/he does not have enough experience to perform spatial operations by using the original land cover data in GIS software, thus would like to import some CAD data about the changes in UMZs from the relevant databases in the AM data model, overlay it onto her/his own study area (i.e. the buffer area of 10km) again in CAD environment, and produce desired maps or generate statistics.
+
+
+
Pre-condition
+
The study is focussed on a certain coastal region bordered within a buffer zone of 10 km from the coastline.
+
+
+
Post-condition
+
Spatial display of UMZ changes in coastal region and associated statistics (i.e. the share of increases in the region).
+
+
+
Flow of Events – Basic Path
+
+
+
Step 1
+
Researcher collects spatial data on coastal buffers from 0 to 10 km by NUTS3 through INSPIRE Geo-portal.
+
+
+
Step 2
+
She/he then downloads UMZ data for changes between the available years 1990, 2000 and 2006, again by using INSPIRE Geo-portal, and displays them onto the coastal region.
+
+
+
Step 3
+
Finally she/he computes a set of spatial statistics (e.g. total amount of increases and/or decreases inside the region, the rates of changes to the total area, etc.).
+
+
+
Flow of Events – Alternative Paths
+
+
+
Step 1a
+
Researcher collects spatial data on coastlines through INSPIRE Geo-portal.
+
+
+
Step 1b
+
She/he isolates the coastal area of her/his interest and generates a 10km inside buffer zone to define the coastal region.
+
+
+
Step 2a
+
She/he downloads UMZ data for the years 1990, 2000 and 2006 from the web pages of data-provider by using INSPIRE Geo-dataportal’s download services.
+
+
+
Step 2b
+
Researcher spatially computes UMZ changes in the periods 1990-2000, 2000-2006 and 1990-2006 on her/his own desktop GIS application.
+
+
+
Data set: Europe’s coastal buffer of 10km by NUTS3
Data set: UMZ dynamics within the coastal zone of interest
+
+
+
Description
+
UMZ coverage and shares to generate spatial statistics for the coastal zone of interest.
+
+
+
Data provider
+
Researcher’s institute/university.
+
+
+
Type
+
output
+
+
+
Geographic scope
+
Study area
+
+
+
Thematic scope
+
Integrated coastal zone management.
+
+
+
Scale, resolution
+
1:100.000
+
+
+
Delivery
+
For private use
+
+
+
Documentation
+
Research report
+
+
+
+
+
+
+
+
+
+
Figure B4.1 – Example UML use case diagram
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
(a)
+
(b)
+
(c)
+
+
+
+
+
Figure B4.2 – (a) Europe’s territories and coastline, (b) coastal buffer zone of 10km, and (c) UMZ changes inside the coastal zone of interest
+
+
+
+
B.5. State of the environment assessment: Air Quality
+
+
+
+
+
+
+
+
Use Case Description
+
+
+
+
+
Name
+
Air quality: Ambient air quality assessment.
+
+
+
Primary actor
+
Policy Analyst from the Commission Services / European Environment Agency
+
+
+
Goal
+
Assessment of the state of EU-wide air quality to support re-defining measures to improve air quality for areas with concentrations above EU air quality thresholds.
+
+
+
System under
+consideration
+
AirBase: public air quality database.
+
+
+
Importance
+
High
+
+
+
Description
+
The Clean Air for Europe Directive (2008/50/EC) requires Member States (MS) to divide their territory into air quality management zones. Within these zones, Member States should annually assess ambient air quality levels against air quality objectives for the protection of human health and the environment. Air Quality Management Zones may be delimited to define measures for different pollutants to optimize management of air quality due to differences in source and abatement strategies. Where levels are elevated, Member States should prepare an air quality management plan or action programme to ensure compliance with the regulatory objectives (e.g. exceedance of limit or threshold values) before the date when they enter into force. Once established, regular assessment shall be undertaken to identify whether MS are attaining the environmental objectives set within individual zones and whether the air quality management plan or action programme needs to be revised.
+
+
+
Pre-condition
+
+
+
+
A competent authority that is responsible for the management of air quality must be in place (2008/EC/50 Art. 3).
+
+
+
Inventory of relevant monitoring stations and relevant metadata must be in place.
+
+
+
Inventory of models if used must be in place.
+
+
+
Information on population must be in place in order to establish whether the zone should be identified as an agglomeration.
+
+
+
+
+
+
Post-condition
+
Air quality data viewer, air quality maps, air quality statistics at reporting stations, spatial display of the zones in relation to EU air quality thresholds.
+
+
+
Flow of Events – Basic Path
+
+
+
Step 1
+
+
Defining management zones:
+
+
+
(For health, the entire territory must be covered (no gaps allowed; lakes included, seas excluded); while for environment/ecosystems, no continuity required)
+
+
+
MS have to deliver the boundaries of the management zones. MS are allowed to provide either GIS files, or a set of administrative units that form the zones. Current reporting LAU2 is the requested level (in order to avoid problems with overlaps, donut-structures, etc.). MS are allowed to have different zones for different objectives.
+
+
+
+
Step 2
+
+
Considering resident population:
+
+
+
MS need to provide population figures and relevant reference year for each zone as well as marking if the zone is an agglomeration (>250k inh. or <250k inh., but with a given (high) population density, to be decided upon by the MS) or non-agglomeration.
+
+
+
+
Step 3
+
+
Defining the assessment regime within the zones (5-yearly cycle):
+
+
+
MS have to establish the assessment regime: investigate off-line air quality in order to know if additional measurement stations are needed, or if modelling is a valid approach, or expert judgement (indicative monitoring). The Directive sets out the rules for establishing the number and density of sampling points which must be in operation in order to provide the data for the assessment. Art 6, 7 and 8. If there is a lack of stations, MS need to set up additional stations.
+
+
+
+
Step 4
+
+
Making available preliminary information to EC (2011/850/EU):
+
+
+
All information of steps 1 – 3 is to be transmitted to the EC, including the list of stations. This has to be done before the actual monitoring starts (different as compared to the current situation in which info can be provided afterwards).
+
+
+
+
Step 5
+
+
Starting the monitoring:
+
+
+
The up to date data for the appropriate pollutants is made available as quickly as possible. The data is preliminary as it has not yet undergone the full national QA. Exceedances (as defined by the Directive) are made available as a warning to the public (min. point data, potentially extrapolated to zone data).
+
+
+
+
Step 6
+
+
Validation of the monitored data (yearly basis):
+
+
+
MS have to validate their data according to the data quality objectives as set out by the Directive. Statistics are to be calculated and compared with the environmental objectives set out in the Directive. Effects from natural events and winter sanding are allowed to be deducted from the statistics before comparison with the environmental objectives for specified pollutants: without these, the objectives might not have been met. Accounting of the values per pollutant, per limit value and per zone is to be made.
+
+
+
+
Step 7
+
+
Making available final information to EC:
+
+
+
The accounting is reported to the EC, together with all the relevant primary data (by way of evidence underpinning the accounting). Explicit linkage of the data-series with zone, station, pollutant, instrument, etc. has to be included. This information is required not more than nine months after the end of the calendar year in which the monitoring took place (2011/850/EC).
+
+
+
+
Step 8
+
+
Analysis and Planning:
+
+
+
Analysis and planning is undertaken to identify new measures or revisions to existing measures that will cause pollutant values to fall below regulatory maximum limits. These must be reported within 24 months of the failure to meet an environmental objective. The report must link back to the original data.
+
+
+
Remark: the Directive foresees time extensions for certain pollutants in certain zones under specific conditions. The EC grants these extensions, which then feed back into the system (steps 1 to 6). However, the time extensions are linked to the definition of the zones; so re-arranging zones entails that historic zoning needs to be traceable, since linked with the time extensions on the pollutant values.
+
+
+
+
Flow of Events – Alternative Paths
+
+
+
+
NONE
+
+
+
Data set: Management Zones
+
+
+
Description
+
Management zones/units (administrative boundaries (GISCO MS-data)) defined by Member States.
Figure B5.2 – Air quality reporting stations in EU and EEA Member & Collaborating Countries
+
+
+
+
+
+
+
+
+
+
+
+
+
Figure B5.3 – EU-wide mapping of management/reporting zones with respect to air pollution levels (PM10, lead, etc.) as of the year 2007 against EU air quality thresholds.
+
+
+
+
+
+
+
Annex C: Code list values - (normative)
+
+
+
C.1. INSPIRE Application Schema 'Area Management Restriction and Regulation Zones'
+
+
EnvironmentalDomain
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
environmental domain
+
+
+
Definition:
+
Environmental domain, for which environmental objectives can be defined.
The allowed values for this code list comprise the values specified in the INSPIRE Regsitry and additional values at any level defined by data providers.
D.1. Regulated fairways at sea or large inland waters
+
+
Example based on Norway and information available from the Norwegian Coastal Administration (www.kystverket.no)
+
+
+
D.1.1. Description of type of area
+
+
Fairways (or the equal term waterways) at sea are a term that has different types of meaning, depending on perspective and approach. The most common are:
+
+
+
+
+
Fairways as a generic term for most appropriate way of navigation. The general rule for transportation on the sea is that any ship may sail at any place, unless given restrictions are defined (e.g. related to type of goods, need for pilot, military areas, national boundaries, custom, etc.) – and as long as the physical restrictions related to width and depth are met.
+
+
Fairway in this context is related to routes which have been modified or supported for sea navigation, e.g. by lighthouses and buoys or by physical modification of the terrain (dredging or blasting rocks).
+
+
+
+
+
+
+
+
Fairways – as approved routes for navigating with or without pilot. A captain may be certified to navigate a certain fairway without a pilot. A dedicated fairway certificate is then issued.
+
+
+
Fairways, restricting navigation in a given area, e.g. traffic going in one direction in one area – and the other in the opposite area. Typically at large ports.
+
+
+
Fairways – given as areas reserved for sea navigation, implying a different type management and usage regime.
+
+
+
+
+
For the INSPIRE Area Management theme, it is only (d) that is relevant (the others relate to navigation and transport).
+
+
+
+
+
+
+
+
Fairways under area management are hence defined as areas at sea or inland lakes that have defined certain restrictions or management regimes that are related to maintain navigation and transport on water.
+
+
+
+
+
+
D.1.2. Legal basis
+
+
The legal basis for fairways defined as (d) above is based on Norwegian legislation and regulations;
+
+
+
+
+
Law: LOV-2009-04-17-19-§9 and LOV-2009-04-17-19-§16
+
+
+
Regulation ("forskrift"): FOR 2009-11-30 nr 1477: Forskrift om farleder
Fairways (main and secondary) line with fairway number,
+
+
+
The area delimitation defined by the fairway, or by harbours defined through the regulation.
+
+
+
+
+
+
+
+
+
+
A spatial dataset is given and is presented through a web-map portal and formally integrated in the regulation (the web-map portal is a part of the regulation – which is unique for a regulation in Norway) - http://kart.kystverket.no/farledsforskrift
+
+
+
The fairway ends at the entrance of a defined harbour area.
+
+
+
Within a fairway area, the Ministry of Fisheries and Coastal Affairs, or any department acting on their behalf, has regulation and management authority. For areas outside, areas are managed and regulated as per common Norwegian law by private owners, municipalities, counties and the state.
+
+
+
The purpose of the regulated fairway area is to ensure that no physical or administrative interventions are imposed on these areas limiting their usage for maritime navigation. Typically interventions that are limited are fish farming and construction work.
+
+
+
+
D.1.3. Spatial structure
+
+
+
+
+
+
+
The spatial representation of the regulated fairway consists of the following spatial data:
+
+
+
+
+
Line dataset – indicating the fairway itself,
+
+
+
Polygon dataset – delimiting the defined regulated fairway area,
+
+
+
Line dataset – indicates the entrance to a defined harbour area.
+
+
+
+
+
The spatial data has been generated by creating buffers along the defined fairway lines and overlaying these with land or other constructions.
+
+
+
The data is available for download, or as a WMS service from the Norwegian Coastal Administration through Norway Digital (the Norwegian national SDI implementation).
+
+
+
+
D.1.4. Description of tasks – questions that data can answer
+
+
The regulated fairway can be used for two main purposes:
+
+
+
+
+
Defines clearly who has authority to plan, approve and make interventions within the defined area,
+
+
+
Indicates that the area is reserved for maritime navigation, and shall hence be restrictive for interventions.
+
+
+
+
+
+
D.1.5. Any specific data quality requirements
+
+
The fairway delineation data is defined by regulations (i.e. not measured in the field or otherwise collected) and is thus correct as per the legal definition, assuring 100% data quality.
+
+
+
+
D.1.6. Illustrations – screen shots
+
+
+
+
+
+
+
Figure D1.6.1– The fairway regulation.
+
+
+
+
+
+
+
+
Figure D1.6.212 – Web map portal – integrated as part of the regulation. Through the interface, the data can be downloaded as an excel file, shape file or SOSI (the Norwegian spatial data exchange format) – in WGS 84 / EUREF89, UTM 33.
+
+
+
+
+
+
+
+
Figure D1.6.3 – Illustration of the data for the Oslo fjord.
+
+
+
+
+
+
+
+
Figure D1.6.4 – Detailed illustration of Larvik harbor, including its delimitation of the harbor itself (black and white dashed line)
+
+
+
+
+
D.2. Data model support for restricted areas around drinking water source
+
+
D.2.1. Needs for allocating protection zones around drinking water bodies
+
+
The Water Framework Directive (WFD), which established a new, integrated approach to the protection, improvement and sustainable use of surface waters, imposes some requirements on Member States to take account of pressures on water quality from point and diffuse sources, and to ensure that necessary measures to meet quality objectives are selected. One way of preventing the water bodies from being polluted by many different kinds of pollutants is to design certain protection zones adjacent to those indicated water bodies. In the broader sense, such conservation areas not only improve water quality by removing sediment, fertilizers, pesticides, pathogens, and other potential contaminants from runoff, but also control soil erosion by both wind and water, improve soil quality, enhance fish and wildlife habitat, reduce flooding, conserve energy, protect buildings, roads, and livestock, and conserve biodiversity.
+
+
+
+
D.2.2. Designing reservoir protection zones at various distances from the reservoir
+
+
While establishing zones around surface water bodies for protecting the quality of drinking water from potential pollution arising from their catchments, a variety of methods may be used. In the "Time of Travel (TOT)" method, the protection zone is defined by a threshold travel time that is computed along drainage networks down to the reservoir and that is typically based on the response times for controlling point pollution or on times desired within the protection zone for rehabilitating the quality of polluted water originating from non-point sources. In the fixed-distance method, setbacks from reservoir boundaries, tributaries, or the intakes are established by assigning certain fixed distances.
+
+
+
+
+
+
+
+
Figure D2.1 – Application of a fixed-distance protection zone around a reservoir
+
+
+
Reservoir protection zones can be designed as a set of subsequent zones, e.g. absolute zone closest to the reservoir boundaries, proximate and mediate zones with bigger distances from the reservoir and remote zone covering the entire catchment, to secure overall water pollution prevention in catchments of drinking water sources. In such a case, the application of rules and restrictions assigned to the zones changes gradually between the zones, generally by increasing the protective measures as the zone gets closer to the water body, e.g. adapting proper vegetation types and densities for different ranges; sorting out of the restricted/prohibited activities, etc..
+
+
+
+
D.2.3. Example modelling of reservoir protection zones as spatial objects (based on the "Area Management/Restriction/Regulation Zones and Reporting Units (AM)" specification)
+
+
The figure below indicates how a reservoir protection zone is modelled as a spatial entity in the data model prepared for the INSPIRE spatial data theme "Area Management/Restriction/Regulation Zones and Reporting Units (AM)".
+
+
+
+
+
+
+
+
Figure D2.2 – Modelling restricted areas around drinking water sources in TWG-AM data model
+
+
+
+
+
D.3. Data model support for WFD river basin districts
+
+
D.3.1. River basin districts as defined by the Water Framework Directive
+
+
A river basin district is the area of land and sea, made up of one or more neighbouring river basins together with their associated groundwaters and coastal waters, which is identified under Article 3(1) (of the Water Framework Directive) as the main unit for management of river basins. [definition source: Directive 2000/60/EC of 23 October 2000 establishing a framework for Community action in the field of water policy (Water Framework Directive).]
+
+
+
+
D.3.2. Modelling of river basin districts as spatial objects in AM data model structure
+
+
The figure below indicates how river basin districts are modelled as spatial entities in the data model prepared for the INSPIRE spatial data theme "Area Management/Restriction/Regulation Zones and Reporting Units (AM)" (partially by using legislation references and the specific zone type assigned).
+
+
+
+
+
+
+
+
Figure D3.1 – Partial modelling example of river basin districts within the TWG-AM data model
+
+
+
+
+
+
+
+
+
+
+
+
+
Figure D3.2 – Sample links between the RBD spatial object, related data types and code lists defined in the data model
+
+
+
+
+
D.4. Data model support for Nitrate Vulnerable Zones designated in accordance with the Nitrates Directive
+
+
D.4.1. Reporting obligations for Nitrates Directive and designations of nitrate vulnerable zones
+
+
Council Directive 91/676/EEC (the Nitrates Directive) concerning the protection of waters against pollution caused by nitrates from agricultural sources was adopted on 12 December 1991. Article 10 of the Nitrates Directive requires Member States to submit a report to the Commission every four years following its notification. This report should contain information pertaining to codes of good agricultural practice, designated vulnerable zones, the results of water monitoring and a summary of the relevant aspects of action programmes drawn up in relation to nitrate vulnerable zones (source: SEC(2011)909).
+
+
+
Nitrate vulnerable zones, designated by Member States for the protection of Europe’s waters against nitrate pollutions, are included in the AM model structure through the model components designed to cover the specific zone type 'nitrateVulnerableZone' as a management zone and the relevant legislative reference.
+
+
+
+
D.4.2. Modelling of nitrate vulnerable zones in AM data model structure
+
+
+
+
+
+
+
Figure D4.1 – Partial modelling example of nitrate vulnerable zones
+
+
+
+
+
+
+
+
Annex E: Application schema Water Framework Directive - (informative)
+
+
+
This Annex describes an application schema containing management / restriction / regulation zones relevant for the Water Framework Directive (WFD, 2000/60/EC). This application schema contains the WFD candidate types that were defined by the Annex I TWG on Hydrography.
+
+
+
The application schema presented in this Annex has been discussed and agreed between the themes on Area Management/Restriction/Regulation Zones and Reporting Units, Environmental monitoring facilities and Geology & Mineral resources. It will be further developed by the relevant WFD / WISE working groups and should thus be considered as an example thematic extension at this stage.
+
+
+
The spatial object types in this application schema are considered as specific sub-types of the ManagementRestrictionOrRegulationZone spatial object type defined in the Area Management Restriction and Regulation Zones application schema. The application schema for WFD is therefore considered as a thematic extension. As a consequence, the spatial object types included in this application schema would not from part of the Implementing Rule for interoperability of spatial data sets and services.
+
+
+
As an example for the WFD domain-specific extension of the generic Area Management Restriction and Regulation Zones application schema it would be used by the relevant WFD/WISE guidelines as they align with INSPIRE.
+
+
+
E.1. Narrative description
+
+
The definition of water bodies in the Water Framework Directive (2000/60/EC) state that: "Water bodies form the principle management units for the protection of water resources". Therefore they fall within the scope of the theme "Area Management/Restriction/Regulation Zones and Reporting Units, alongside River Basin Districts.
+
+
+
The Area Management Restriction and Regulation Zones application schema is very generic and does not include specialised classes, attributes or associations for address domain-specific requirements. To determine what type of Management Area is being represented two code list-valued attributes are used:
+
+
+
+
+
zoneTypeCode
+
+
+
specialisedZoneTypeCode
+
+
+
+
+
Management units as defined in the WFD can be described using the generic ManagementRestrictionOrRegulationZone spatial object type with the value waterBodyForWFD as the zoneTypeCode. Specific types of water body could then be defined using the specialisedZoneTypeCode.
+
+
+
However, a set of candidate types representing WFD water bodies were defined by HY during the Annex I development:
+
+
+
+
+
WFDWaterBody as an abstract base type for the following concrete spatial object types
+
+
+
WFDGroundWaterBody for WFD groundwater bodies
+
+
+
WFDSurfaceWaterBody for WFD surface water bodies
+
+
+
WFDCoastalWater for WFD coastal water bodies
+
+
+
WFDTransitionalWater for WFD transitional waters
+
+
+
WFDRiver for WFD rivers
+
+
+
WFDLake for WFD lakes
+
+
+
+
+
This application schema retains the proposed candidate types, but proposes the following minor amendments:
+
+
+
+
+
All WFD spatial object types now specialise from ManagementRegulationAndRestrictionZone rather than HydroObject (HY).
+
+
+
WFDWaterBody is removed, since the new new super-class ManagementRegulationAndRestrictionZone provides all attributes previously included in WFDWaterBody and no additional constraints or associations are defined for this type.
+
+
+
Two association roles (relatedSurfaceWaterBody and relatedGroundWaterBody) are added to replace the associationRole relatedHydroObject that is lost by changing the super-class to ManagementRegulationAndRestrictionZone.
+
+
+
The following properties are removed, since they are now inherited from the new super-class ManagementRegulationAndRestrictionZone:
+
+
+
+
inspireId
+
+
+
geometry
+
+
+
beginLifespanVersion
+
+
+
endLifespanVersion
+
+
+
+
+
+
The following properties are replace by equivalent properties now inherited from the new super-class ManagementRegulationAndRestrictionZone:
+
+
+
+
geographicalName is replaced by name
+
+
+
hydroId is replaced by thematicId
+
+
+
+
+
+
+
+
+
E.2. UML overview
+
+
Figure gives an overview of the complete application schema.
+
+
+
+
+
+
+
+
Figure E2.1 – UML class diagram: Overview of the Water Framework Directive application schema
+
+
+
Figure E2.1 gives an overview of the relationships to spatial objects in the themes Hydrography (through the association role relatedSurfaceWaterBody) and Geology (through the association roles relatedGroundWaterBody and relatedHydrogeologicalUnit).
+
+
+
+
+
+
+
+
Figure E2.2 – UML class diagram: Relationships between the Water Framework Directive application schema and the spatial data themes Hydrography and Geology
+
+
+
E.2.1. Consistency between spatial data sets
+
+
Besides the requirements and / or recommendations stated for the base application scheme the following applies to this application schema.
+
+
+
The Reporting schema provides a framework for water related reporting (more specifically the Water Framework Directive). European water reporting is expected to extend specific reporting obligation formats from this application scheme. Therefore there must be compatibility with information reported under these directives (specifically the Water Framework Directive [2000/60/EC]). The specific reporting obligations are likely to be updated to reflect the example and align with the specifics of INSPIRE.
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 2
+
+
+
All attribution of objects in this schema shall be the same as the equivalent property of that object used for reporting obligations under Directive [2000/60/EC].
+
+
+
+
+
+
+
+
E.2.2. Identifier management
+
+
Besides the requirements and / or recommendations stated for the base application scheme the following applies to this application schema.
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 3
+
+
+
The localId attribute of the external object identifier of a spatial object shall be the same as the ID used for reporting obligations under the Water Framework Directive [2000/60/EC].
+
+
+
+
+
+
+
+
E.2.3. Modelling of object references
+
+
No additional requirements and / or recommendations are required beyond those stated for the base application scheme.
+
+
+
+
E.2.4. Geometry representation
+
+
Besides the requirements and / or recommendations stated for the base application scheme the following applies to this application schema.
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 4
+
+
+
The geometry shall be the same as the geometry used for reporting obligations under the Water Framework Directive [2000/60/EC]
+
+
+
+
+
+
+
+
E.2.5. Temporality representation
+
+
No additional requirements and / or recommendations are required over and on top of those stated for the base application scheme.
+
+
+
+
+
E.3. Feature catalogue
+
+
Feature catalogue metadata
+
+
+
+
+
+
+
+
+
Application Schema
+
INSPIRE Application Schema Water Framework Directive
+
+
+
Version number
+
3.0
+
+
+
+
+
Types defined in the feature catalogue
+
+
+
+
+
+
+
+
+
+
Type
+
Package
+
Stereotypes
+
+
+
+
+
WFDCoastalWater
+
Water Framework Directive
+
«featureType»
+
+
+
WFDGroundWaterBody
+
Water Framework Directive
+
«featureType»
+
+
+
WFDLake
+
Water Framework Directive
+
«featureType»
+
+
+
WFDRiver
+
Water Framework Directive
+
«featureType»
+
+
+
WFDRiverOrLake
+
Water Framework Directive
+
«featureType»
+
+
+
WFDSurfaceWaterBody
+
Water Framework Directive
+
«featureType»
+
+
+
WFDTransitionalWater
+
Water Framework Directive
+
«featureType»
+
+
+
+
+
E.3.1. Spatial object types
+
+
E.3.1.1. WFDCoastalWater
+
+
+
+
+
+
+
WFDCoastalWater
+
+
+
+
+
+
+
+
+
+
+
+
Subtype of:
+
WFDSurfaceWaterBody
+
+
+
Definition:
+
Surface water on the landward side of a line, every point of which is at a distance of one nautical mile on the seaward side from the nearest point of the baseline from which the breadth of territorial waters is measured, extending where appropriate up to the outer limit of transitional waters.
+
+
+
Description:
+
SOURCE [2000/60/EC Art. 2(7)].
+
+NOTE All WFD spatial object types are regarded as example extensions of the ManagementAreaRestrictionOrRegulationZone spatial object type whose content needs to be further discussed with the relevant WISE and WFD reporting working groups.
+
+
+
Stereotypes:
+
«featureType»
+
+
+
+
+
+
+
Constraint: geometryIsSurface
+
+
+
+
+
+
+
+
+
Natural language:
+
Coastal water geometry must be a surface
+
+
+
OCL:
+
inv: self→count(geometry)=1 and self.geometry.oclIsTypeOf(GM_Surface)
+
+
+
+
+
+
+
+
+
E.3.1.2. WFDGroundWaterBody
+
+
+
+
+
+
+
WFDGroundWaterBody
+
+
+
+
+
+
+
+
+
+
+
+
Subtype of:
+
ManagementRestrictionOrRegulationZone
+
+
+
Definition:
+
A distinct volume of groundwater within an aquifer or aquifers.
+
+
+
Description:
+
SOURCE [2000/60/EC Art. 2(12)].
+
+NOTE All WFD spatial object types are regarded as example extensions of the ManagementAreaRestrictionOrRegulationZone spatial object type whose content needs to be further discussed with the relevant WISE and WFD reporting working groups.
+
+
+
Stereotypes:
+
«featureType»
+
+
+
+
+
+
+
Association role: relatedGroundWaterBody
+
+
+
+
+
+
+
+
+
Name:
+
related groundwater body
+
+
+
Value type:
+
GroundWaterBody
+
+
+
Definition:
+
The natural groundwater body that the WFDGroundWaterBody is related to.
+
+
+
Description:
+
Based on the different assumptions established in Member States the delineation of a WFDGroundWaterBody boundary can differ from the natural GroundWaterBody extent.
+
+
+
Multiplicity:
+
1..*
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
+
+
E.3.1.3. WFDLake
+
+
+
+
+
+
+
WFDLake
+
+
+
+
+
+
+
+
+
+
+
+
Subtype of:
+
WFDRiverOrLake
+
+
+
Definition:
+
A body of standing inland surface water.
+
+
+
Description:
+
SOURCE [2000/60/EC Art. 2(5)].
+
+NOTE All WFD spatial object types are regarded as example extensions of the ManagementAreaRestrictionOrRegulationZone spatial object type whose content needs to be further discussed with the relevant WISE and WFD reporting working groups.
+
+
+
Stereotypes:
+
«featureType»
+
+
+
+
+
+
+
Constraint: geometryIsSurface
+
+
+
+
+
+
+
+
+
Natural language:
+
Lake geometry must be a surface
+
+
+
OCL:
+
inv: self→count(geometry)=1 and self.geometry.oclIsTypeOf(GM_Surface)
+
+
+
+
+
+
+
+
+
E.3.1.4. WFDRiver
+
+
+
+
+
+
+
WFDRiver
+
+
+
+
+
+
+
+
+
+
+
+
Subtype of:
+
WFDRiverOrLake
+
+
+
Definition:
+
A body of inland water flowing for the most part on the surface of the land but which may flow underground for part of its course.
+
+
+
Description:
+
SOURCE [2000/60/EC Art. 2(4)].
+
+NOTE All WFD spatial object types are regarded as example extensions of the ManagementAreaRestrictionOrRegulationZone spatial object type whose content needs to be further discussed with the relevant WISE and WFD reporting working groups.
+
+
+
Stereotypes:
+
«featureType»
+
+
+
+
+
+
+
Constraint: geometryIsCurve
+
+
+
+
+
+
+
+
+
Natural language:
+
River geometry must be a curve
+
+
+
OCL:
+
inv: self→count(geometry)=1 and self.geometry.oclIsTypeOf(GM_Curve)
+
+
+
+
+
+
+
Constraint: mainAndLargeNotForCanals
+
+
+
+
+
+
+
+
+
Natural language:
+
Main and large attributes may not be specified for canals
+
+
+
OCL:
+
inv: if self.artificial = True) or (self.heavilyModified = True then self→count(main)=0) and (self→count(large)=0
+
+
+
+
+
+
+
+
+
E.3.1.5. WFDRiverOrLake
+
+
+
+
+
+
+
WFDRiverOrLake (abstract)
+
+
+
+
+
+
+
+
+
+
+
+
Subtype of:
+
WFDSurfaceWaterBody
+
+
+
Definition:
+
Abstract class containing common attributes for a WFD river or lake.
+
+
+
Description:
+
NOTE All WFD spatial object types are regarded as example extensions of the ManagementAreaRestrictionOrRegulationZone spatial object type whose content needs to be further discussed with the relevant WISE and WFD reporting working groups.
+
+
+
Stereotypes:
+
«featureType»
+
+
+
+
+
+
+
Attribute: large
+
+
+
+
+
+
+
+
+
Value type:
+
Boolean
+
+
+
Definition:
+
Rivers with a catchment area > 50,000 km2; or rivers and main tributaries that have a catchment area between 5,000 km2 and 50,000 km2. Lakes that have a surface area > 500 km2.
+
+
+
Description:
+
SOURCE [WISE GIS Guidance].
+
+
+
Multiplicity:
+
1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: main
+
+
+
+
+
+
+
+
+
Value type:
+
Boolean
+
+
+
Definition:
+
Rivers that have a catchment area > 500 km2. Lakes that have a surface area > 10 km2.
+
+
+
Description:
+
SOURCE [WISE GIS Guidance].
+
+
+
Multiplicity:
+
1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
+
+
E.3.1.6. WFDSurfaceWaterBody
+
+
+
+
+
+
+
WFDSurfaceWaterBody (abstract)
+
+
+
+
+
+
+
+
+
+
+
+
Subtype of:
+
ManagementRestrictionOrRegulationZone
+
+
+
Definition:
+
A discrete and significant element of surface water.
+
+
+
Description:
+
SOURCE [Based on 2000/60/EC Art. 2(10)].
+
+EXAMPLE A lake, a reservoir, a stream, river or canal, part of a stream, river or canal, a transitional water or a stretch of coastal water.
+
+NOTE 1 The surface water bodies shall be identified as falling within either one of the following surface water categories - rivers, lakes, transitional waters or coastal waters - or as artificial surface water bodies or heavily modified surface water bodies. [2000/60/EC Ann. II 1.1(ii)]
+
+NOTE 2 All WFD spatial object types are regarded as example extensions of the ManagementAreaRestrictionOrRegulationZone spatial object type whose content needs to be further discussed with the relevant WISE and WFD reporting working groups.
+
+
+
Stereotypes:
+
«featureType»
+
+
+
+
+
+
+
Attribute: artificial
+
+
+
+
+
+
+
+
+
Value type:
+
Boolean
+
+
+
Definition:
+
'Artificial water body' means a body of surface water created by human activity.
+
+
+
Description:
+
SOURCE [2000/60/EC Art. 2(8)].
+
+
+
Multiplicity:
+
1
+
+
+
+
+
+
+
Attribute: heavilyModified
+
+
+
+
+
+
+
+
+
Value type:
+
Boolean
+
+
+
Definition:
+
'Heavily modified water body' means a body of surface water which as a result of physical alterations by human activity is substantially changed in character, as designated by the Member State in accordance with the provisions of WFD Annex II.
+
+
+
Description:
+
SOURCE [2000/60/EC Art. 2(9)].
+
+
+
Multiplicity:
+
0..1
+
+
+
+
+
+
+
Attribute: representativePoint
+
+
+
+
+
+
+
+
+
Value type:
+
GM_Point
+
+
+
Definition:
+
Representative point of the WFD water body.
+
+
+
Multiplicity:
+
1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Association role: relatedSurfaceWaterBody
+
+
+
+
+
+
+
+
+
Value type:
+
HydroObject
+
+
+
Multiplicity:
+
1..*
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Constraint: invalidArtificalAndHeavilyModified
+
+
+
+
+
+
+
+
+
Natural language:
+
heavilyModified attribute allowed only if not artificial
+
+
+
OCL:
+
inv: if (self.artificial = True) then (self→count(heavilyModified)=0)
+
+
+
+
+
+
+
+
+
E.3.1.7. WFDTransitionalWater
+
+
+
+
+
+
+
WFDTransitionalWater
+
+
+
+
+
+
+
+
+
+
+
+
Subtype of:
+
WFDSurfaceWaterBody
+
+
+
Definition:
+
Bodies of surface water in the vicinity of river mouths which are partly saline in character as a result of their proximity to coastal waters but which are substantially influenced by freshwater flows.
+
+
+
Description:
+
SOURCE [2000/60/EC Art. 2(6)].
+
+NOTE All WFD spatial object types are regarded as example extensions of the ManagementAreaRestrictionOrRegulationZone spatial object type whose content needs to be further discussed with the relevant WISE and WFD reporting working groups.
+
+
+
Stereotypes:
+
«featureType»
+
+
+
+
+
+
+
Constraint: geometryIsSurface
+
+
+
+
+
+
+
+
+
Natural language:
+
Transitional water geometry must be a surface
+
+
+
OCL:
+
inv: self→count(geometry)=1 and self.geometry.oclIsTypeOf(GM_Surface)
+
+
+
+
+
+
+
+
+
+
E.3.2. Imported types (informative)
+
+
This section lists definitions for feature types, data types and code lists that are defined in other application schemas. The section is purely informative and should help the reader understand the feature catalogue presented in the previous sections. For the normative documentation of these types, see the given references.
+
+
+
E.3.2.1. Boolean
+
+
+
+
+
+
+
Boolean
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
Truth
+
+
+
Reference:
+
Geographic information — Conceptual schema language [ISO/TS 19103:2005]
+
+
+
+
+
+
+
+
+
E.3.2.2. GM_Point
+
+
+
+
+
+
+
GM_Point
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
Geometric primitive
+
+
+
Reference:
+
Geographic information — Spatial schema [ISO 19107:2003]
+
+
+
+
+
+
+
+
+
E.3.2.3. GroundWaterBody
+
+
+
+
+
+
+
GroundWaterBody
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
Hydrogeology
+
+
+
Reference:
+
INSPIRE Data specification on Geology [DS-D2.8.II.4]
+
+
+
Definition:
+
A distinct volume of groundwater within an aquifer or system of aquifers, which is hydraulically isolated from nearby groundwater bodies.
+
+
+
Description:
+
Groundwater bodies form the principal management units under the European Water Framework Directive (2000/60/CE, 2000). They should be hydraulically continuous entities, and must be defined on the basis of flow or abstraction, and are inextricably linked to surface water bodies.
+
+
+
+
+
+
+
+
+
E.3.2.4. HydroObject
+
+
+
+
+
+
+
HydroObject (abstract)
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
Hydro - base
+
+
+
Reference:
+
INSPIRE Data specification on Hydrography [DS-D2.8.I.8]
+
+
+
Definition:
+
An identity base for hydrographic (including man-made) objects in the real world.
+
+
+
Description:
+
NOTE Derived 'views' of real-world hydrographic objects are represented through specialisations in other application schemas; all representations of the same real-world object share a common geographic name or hydrographic identifier.
+
+
+
+
+
+
+
+
+
E.3.2.5. ManagementRestrictionOrRegulationZone
+
+
+
+
+
+
+
ManagementRestrictionOrRegulationZone
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
Controlled Activities
+
+
+
Reference:
+
INSPIRE Data specification on Area Management Restriction Regulation Zones and Reporting units [DS-D2.8.III.11]
+
+
+
Definition:
+
Area managed, restricted or regulated in accordance with a legal requirement related to an environmental policy or a policy or activity that may have an impact on the environment at any level of administration (or used for reporting at international, European, national, regional and local) levels.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Annex F: Extending the Area Management, Restriction and Regulation Zones Application Schema - (informative)
+
+
+
F.1. Requirements for Extending INSPIRE AM Application Schema
+
+
There are two key requirements for extending the Area Management Restriction and Regulation Zones Application Schema:
+
+
+
+
+
Defining Thematic Community or Member State code lists.
+
+
+
Developing thematic data specifications that extend the Area Management Restriction and Regulation Zones Application Schema.
+
+
+
+
+
+
F.2. Defining Thematic Community or Member State code lists
+
+
Within the Area Management, Restriction and Regulation Zones Application Schema there are several properties defined whose value is intended to be taken from a code list. Some of the code lists are defined within the INSPIRE Area Management, Restriction and Regulation Zones Application Schema, whereas others are intended to be derived from code lists defined by thematic communities or Member States.
+
+
+
In the Area Management, Restriction and Regulation Zones Application Schema contained in the Implementing Rule, the value defined for the specialisedZoneType should be derived from an external code list as the SpecialisedZoneTypeCode [CodeList] is an abstract, empty placeholder code list.
+
+
+
This section provides some example specialised zone type code lists that could be defined for specific zone types defined in the ZoneTypeCode code list (see Figure ).
+
+
+
The mechanism for defining specialised zone type code lists for SpecialisedZoneTypeCode is to develop a code list that extends the SpecialisedZoneTypeCode defining the codelist values for a specific zone type.
+
+
+
Recommendations for defining SpecialisedZoneType codelists
+
+
+
When defining a code list for SpecialisedZoneType values related to a specific INSPIRE zoneType, it is recommended that:
+
+
+
+
+
The name of the code list should include the name of zone type code.
+
+
+
+
+
+
+
The specialisedZoneType codes values should be narrower than the parent zoneType.
+
+
+
+
+
For some zoneTypes, such as animalHealthRestrictionZone and plantHealthProtectionZones, there may be a large number of possible specialisedZoneTypes relating to specific diseases. Where this occurs, multiple SpecialisedZoneTypeCode code lists could be defined to enable different organisations to manage and maintain the code lists relevant to their domain.
+
+
+
+
+
+
+
+
Figure F2.1. Example code lists extending SpecialisedZoneTypeCode
+
+
+
This approach can also be followed for the abstract, empty placeholder SpecialisedActivityTypeCode code list in the Controlled Activities Extension Application Schema.Developing thematic data specifications that extend INSPIRE AM Application Schemas.
+
+
+
It is expected that the INSPIRE application schema defined for the INSPIRE Annex themes should form the foundation schemas, along with the ISO/OGC specifications upon which thematic community, Member States and European Commission data specifications are developed. Reporting use cases form many of the key user scenarios that have informed the development of most INSPIRE Annex themes, including AM. It is envisaged that many of the existing EC reporting data specifications will be updated to extend from INSPIRE Application Schema (Figure F2.2).
+
+
+
+
+
+
+
+
Figure F2.2 - Extending INSPIRE Application for the development of thematic data specifications for reporting
+
+
+
This section demonstrates how Thematic Communities and Member States can extend the INSPIRE Application schemas, particularly the application schemas defined in the AM Theme. The example uses a real-world example that was developed for the Air Quality Directive (AQD) e-Reporting Implementing Provision (2011/850/EU).
+
+
+
F.2.1. Reporting and exchanging of Air Quality data under 2011/850/EU
+
+
A number of EU legal instruments require EU Member States to monitor and report air quality data. This information is collated and disseminated by the European Environment Agency (EEA). At present much of the data is reported electronically by countries, but not necessarily in the best integrated fashion. The recent introduction of 2011/850/EU (Commission Implementing Decision of 12 December 2011 laying down rules for Directives 2004/107/EC and 2008/50/EC as regards the reciprocal exchange of information and reporting on ambient air quality) provides an opportunity to examine the reporting process overall to determine how it can be modernised to improve data quality, facilitate data sharing and reduce the administrative burden of reporting.
+
+
+
The Air Quality Directive (AQD) implementing provisions (AQD IPR) will apply from the end of a 2-year transitional period commencing at the date of their adoption. Consequently, the decision applies from 31 December 2013. To successfully manage and facilitate the transition process, the countries' reporting agencies, their data providers, and the EEA operational services will need to work closely together to establish, test and commission a new reporting process. The AQD Directive 2008/50/EC requires that the e-Reporting procedures are compatible with the requirements of the INSPIRE Directive (2007/2/EC).
+
+
+
Reporting and exchange of air quality information under the AQD IPR are of relevance to at least four of the INSPIRE Annex II/III data specification areas:
D2.8.III.11 Area Management/Restriction/Regulation Zones and Reporting Units (AM) and
+
+
+
D2.8.III.13-14 Atmospheric Conditions and Meteorological Geographical Features (AC-MF)
+
+
+
+
+
Future electronic reporting of Air Quality data in Europe will therefore need to use the data specifications from all these thematic areas and it is essential that all four consider the use case of Air Quality data, which now includes both measurement and modelled data.
+
+
+
+
F.2.2. Draft AQD e-Reporting Data Specification
+
+
A draft AQD e-Reporting Data Specification was developed in December 2011 based on version 2.0 of the INSPIRE Annex III data specifications. This data specification is being tested by a group of pilot countries that are supporting the Commission transition to the new e-reporting system with the following mandate (see http://aqportal.eionet.europa.eu/).
+
+
+
NOTE The version of the draft AQD data specification illustrated reflects the changes to the INSPIRE data specifications, and so differs from the version that was tested. The example below demonstrates how to extend the application schema defined in INSPIRE data specifications for the development of new data specifications to support data exchange for reporting for environmental legislation.
+
+
+
+
F.2.3. Extending INSPIRE Data Specifications for developing thematic data specifications
+
+
The INSPIRE Data Specifications was established to provide a core data specification that is applicable across multiple thematic domains. For some INSPIRE Annex themes, extension application schemas have also been developed to meet additional use cases that were identified during development. These can also be used to develop thematic data specifications.
+
+
+
Extending INSPIRE data specifications requires the thematic data specification to create a new thematic application schema package. This shall then contain either:
+
+
+
+
+
One or more spatial objects that extend (i.e. specialise) from the relevant INSPIRE spatial object. This specialised spatial object shall then carry only the additional thematic properties.
+
+
+
One or more sub-packages that contain specific groupings of spatial objects. For example, in the AQD e-Reporting Data Specification, five sub-packages could be generated for each of the key reporting use cases as defined in the Use Case: Reporting and exchanging of Air Quality data under 2011/850/EU document (Figure ):
+
+
+
+
Aggregated Assessment Data
+
+
+
Primary Assessment Data
+
+
+
Assessment Methods
+
+
+
Assessment and Attainment of Environment Objectives
+
+
+
Zones and Agglomerations
+
+
+
+
+
+
+
+
Extending the Area Management, Restriction and Regulation Zones Application Schema
+
+
+
In the Zones and Agglomerations package, the AQD Zone spatial object extends from the ManagementRestrictionOrRegulationZone spatial object. It therefore inherits all of the properties of the ManagementRestrictionOrRegulationZone.
+
+
+
To meet the reporting data requirements for the AQD, only seven additional properties were added. The AQD data specification also extends the SpecialisedZoneTypeCode code list to define the relevant specialised ZoneType values that are applicable to the airQualityManagementZone zoneType. Finally, a constraint is added to the Zone to state that the zoneType shall be airQualityManagementZone (Figure ).
+
+
+
DISCLAIMER: The version of the AQD e-Reporting Data Specification provided in this Annex was developed as an example only. Although it is based on of the original draft data specification it is not officially endorsed. Please do not use.
+
+
+
+
+
+
+
+
Figure F2.3.1 - UML Package Diagram for example Draft AQD e-Reporting Data Specification
+
+
+
+
+
+
+
+
Figure F2.3.2 - UML Class Diagram illustrating the Draft ADQ data specification extending the ManagementRestrictionOrRegulationZone
+
+
+
+
+
+
+
+
Annex G: Identification of Reporting Units in INSPIRE Spatial Data Themes - (informative)
+
+
+
G.1. Overview of reporting units within INSPIRE spatial data themes
+
+
The "reporting unit" within the scope of INSPIRE and the AM theme is a spatial object that provides a spatial reference for the data being reported under an environmental reporting obligation.
+
+
+
It is not the intention of the AM theme to model the feature types (spatial object types) which are used for providing a spatial reference for the data reported under environmental reporting obligations, but they shall be defined and made available according to the requirements of their respective INSPIRE spatial data theme.
+
+
+
The following overview provides some of the examples, identified by the INSPIRE Thematic Working Groups for data specifications development, where it is known that certain spatial object types within the scope of the INSPIRE spatial data themes provide a spatial reference for the data being reported under environmental reporting obligations.
+
+
+
This annex is a "living document" and will evolve in the future on the basis of new understanding and practical experience from implementation of how INSPIRE spatial objects are used as reporting units in environmental reporting obligations.
+
+
+
The table includes the following information:
+
+
+
+
+
Environmental Legislation or Obligation: means the environmental legislation established at different levels – international, European, national or sub-national (regional, local) or other agreed environmental reporting
+
+
+
Reporting Obligation: means the title or description of the specific reporting obligation which is defined within the environmental legislation or agreed environmental reporting;
+
+
+
Annex theme for features: means INSPIRE spatial data theme which includes/defines the spatial object types used in the reporting obligations; acronyms of the INSPIRE spatial data themes are used;
+
+
+
Reporting Unit (Feature type): means the name of the spatial object type (feature type) in the INSPIRE spatial data theme as it is defined in the related INSPIRE Guidelines (data specification);
+
+
+
Related reporting data/information: means more detailed information about the related data that are reported.
+
+
+
+
+
The table is by no means exhaustive and it can be further updated to include more examples of reporting units and to identify close relationships between the INSPIRE spatial data themes, spatial object types and the reporting obligations in the thematic domains.
+
+
+
+
+
+
+
+
+
+
+
+
Environmental Legislation or Other Environmental Reporting
+
Reporting Obligation
+
Annex Theme for Features
+
Reporting Unit (Feature type)
+
Related Reporting Data/Information
+
+
+
+
+
Air Quality Directive (2008/50/EC) - AQD
+
AQD Article 7 - AQD pilot: zones
+
AM
+
+
ManagementRestrictionOrRegulationZone
+
+
+
(zoneType = airQualityManagementZone)
+
+
Zone Descriptions
+
+
+
Air Quality Directive (2008/50/EC) - AQD
+
(F1a) Information on generated aggregated data - primary validated measurements (Article 11)
+
AM
+
+
ManagementRestrictionOrRegulationZone
+
+
+
(zoneType = airQualityManagementZone)
+
+
Aggregated data on zones, includes exceedances, statistics, …
+
+
+
Air Quality Directive (2008/50/EC) - AQD
+
(F1b) Information on generated aggregated data - primary validated modelled (Article 11)
+
AM
+
+
ManagementRestrictionOrRegulationZone
+
+
+
(zoneType = airQualityManagementZone)
+
+
Near-real-time Information and alert threshold information (exceedences) on zones, based on modelled data
+
+
+
Air Quality Directive (2008/50/EC) - AQD
+
(F2) Information on generated aggregated data - primary up-to-date measurements (Article 11)
+
AM
+
+
ManagementRestrictionOrRegulationZone
+
+
+
(zoneType = airQualityManagementZone)
+
+
Near-real-time Information and alert threshold information (exceedences) on zones, based on measured data
+
+
+
Air Quality Directive (2008/50/EC) - AQD
+
(D) Information on the assessment methods (Articles 8 and 9)
+
EF
+
EnvironmentalMonitoringFacility
+
Information on EFs including location and measurement equipment
+
+
+
Air Quality Directive (2008/50/EC) - AQD
+
(E1a) Information on primary validated assessment data -measurements (Article 10)
+
EF
+
EnvironmentalMonitoringFacility
+
+
Primary Data:
+
+
+
+
+
validated observations
+
+
+
+
+
+
Air Quality Directive (2008/50/EC) - AQD
+
(E1b) Information on primary validated assessment data -modelled (Article 10)
+
EF
+
EnvironmentalMonitoringFacility
+
+
Primary Data:
+
+
+
+
+
Modelled data
+
+
+
+
+
+
Air Quality Directive (2008/50/EC) - AQD
+
(E2a) Information on primary up-to-date assessment data -measurements (Article 10)
+
EF
+
EnvironmentalMonitoringFacility
+
+
Primary Data:
+
+
+
+
+
Real-time observations
+
+
+
+
+
+
Air Quality Directive (2008/50/EC) - AQD
+
(F1a) Information on generated aggregated data - primary validated measurements (Article 11)
+
EF
+
EnvironmentalMonitoringFacility
+
Aggregated Data on stations (EF) based on validated measurements
+
+
+
Air Quality Directive (2008/50/EC) - AQD
+
(F1b) Information on generated aggregated data - primary validated modelled (Article 11)
+
EF
+
EnvironmentalMonitoringFacility
+
Aggregated Data on stations (EF) based on modeled data
+
+
+
Air Quality Directive (2008/50/EC) - AQD
+
(F2) Information on generated aggregated data - primary up-to-date measurements (Article 11)
+
EF
+
EnvironmentalMonitoringFacility
+
Aggregated Data on stations (EF) based on Real-time observations
+
+
+
Bathing Water Directive (2006/7/EC) - BWD
+
Management respectively Protection of the Quality of Bathing Waters
+
AM
+
+
ManagementRestrictionOrRegulationZone
+
+
+
(zoneType = bathingWaters)
+
+
+
Bathing water can also be defined as
+
+
+
"element of surface water where the competent authority expects a large number of people to bathe and has not imposed a permanent bathing prohibition, or issued permanent advice against bathing".
+
+
+
Coordination is related to WFD-RBD’s and WFD-SubUnits because a lot of Bathing Waters are situated in WFD-SurfaceWaterbodies (than WB-Code is requested), if they are situated in other Waterbodies NationalUnitCode is requested.
+
+
+
Poor Bathing Water quality or a bad bathing water profile could lead to bathing prohibition or advice against bathing because this is a risk to bathers' health
+
+
+
+
Drinking Water Directive (98/83/EC) - DWD
+
Meeting of quality standards for drinking water
+
AM
+
+
ManagementRestrictionOrRegulationZone
+
+
+
(zoneType = drinkingWaterProtectionArea)
+
+
+
Appropriate water-protection measures should be applied to ensure that surface and groundwater is kept clean, e.g. by establishing safeguard zones with land-use restrictions.
+
+
+
Targeted: all individual supplies of water exceeding 1 000 m³ a day as an average or serving more than 5 000 persons (relation to Art. 7 WFD- waterbodies).
+
+
+
+
Floods Directive (2007/60/EC) - FD
+
Administrative arrangements and coordination in terms of flood risk management
+
AM
+
+
ManagementRestrictionOrRegulationZone
+
+
+
(zoneType = riverBasinDistrict)
+
+
+
ManagementRestrictionOrRegulationZone
+
+
+
(zoneType = floodUnitOfManagement)
+
+
+
Units Of Management
+
+
+
Units of management may be individual river basins and/or certain coastal areas, and may be entirely within national borders or may be part of an international unit of management or international river basin district.
+
+
same information as for WFD-RBD and SubUnits is requested
+
+
+
Floods Directive (2007/60/EC) - FD
+
Areas within flood risk has to be assessed and mitigated
+
AM, NZ
+
+
AM:
+
+
+
ManagementRestrictionOrRegulationZone
+
+
+
(zoneType = riverBasinDistrict)
+
+
+
ManagementRestrictionOrRegulationZone
+
+
+
(zoneType = floodUnitOfManagement)
+
+
+
NZ: RiskZone
+
+
+
Areas with potential significant flood risk (APSFR) on the basis of river basin, sub-basin and/or coastal area or other areas associated with each area of potential significant flood risk.
+
+
Declaration of type(s) of flood(s) which could potentially affect APSFR and what type(s) of adverse consequences will potentially occur
+
+
+
Groundwater Directive (2006/118/EC) - GWD
+
Management of Groundwaterprotection
+
AM
+
+
ManagementRestrictionOrRegulationZone
+
+
+
(zoneType = riverBasinDistrict)
+
+
Same as for WFD-RBD
+
+
+
Groundwater Directive (2006/118/EC) - GWD
+
+
AM
+
+
ManagementRestrictionOrRegulationZone
+
+
+
(zoneType = waterBodyForWFD)
+
+
+
Refers to: groundwaterbodies / groups of groundwaterbodies
+
+
Complementing WFD in terms of pollution: background level, baseline level, pollution trends, compliance with good chemical status criteria etc.
+
+
+
Habitats Directive (92/43/EEC)
+
Reporting every 6 years on the "conservation status" of the habitat types and species protected by the Directive
+
BR
+
Bio-geographicalRegion
+
+
The bio-geographical regions are used for reporting every 6 years on the "conservation status" of the habitat types and species protected by the Directive.
+
+
+
Article 1.iii of the Habitats Directive identifies 9 bio-geographical regions in the EU.
+
+
+
Article 17 of the Habitats Directive requires that every 6 years Member States prepare reports to be sent to the European Commission on the implementation of the Directive.
+
+
+
Article 11 of the Habitats Directive requires Member States to monitor the habitats and species listed in the annexes and Article 17 requires a report to be sent to the European Commission every 6 years following an agreed format – hence the term 'Article 17 Reporting'. The report includes assessments on the conservation status of the habitat types and species of Community interest at the bio-geographical level.
Cooperation in terms of the protection and preserving to maintain or achieve good environmental status in the marine environment
+
AM
+
+
ManagementRestrictionOrRegulationZone
+
+
+
(zoneType = marineRegion) includes related attribute competentAuthority
+
+
+
Declaration of Marine waters, coastal waters (=WFD-Coastalwaterbodies), marine regions or sub-regions and responsible authorities within. Information about "regional cooperation" (means cooperation and coordination of activities between Member States and, whenever possible, third countries sharing the same marine region or subregion, for the purpose of developing and implementing marine strategies); Member States sharing a marine region or subregion shall cooperate to ensure that, within each marine region or subregion, the measures required to achieve the objectives of this Directive, in particular the different elements of the marine strategies referred to in points (a) and (b), are coherent and coordinated across the marine region or subregion concerned.
Marine regions and sub-regions are the geographical basis to provide marine strategies.
+
+
+
Initial assessment of marine waters: (a) an analysis of the essential features and characteristics, and current environmental status of marine waters; (b) an analysis of the predominant pressures and impacts, including human activity; (c) an economic and social analysis of the use of marine waters and of the cost of degradation of the marine environment.
+
+
+
MS provide up-to-date marine strategies for each marine region or sub-region ((a) the initial assessment and the determination of good environmental status; (b) the environmental targets; (c) the monitoring programmes; (d) the programmes of measures).
+
+
+
+
Nitrates Directive (91/676/EEC) - NID
+
Establishment and implementation of action programmes; different programmes may be established for different vulnerable zones or parts of zones.
+
AM
+
+
ManagementRestrictionOrRegulationZone
+
+
+
(zoneType = nitrateVulnerableZone)
+
+
+
Vulnerable zones, parts of vulnerable zones
+
+
+
Waters affected by pollution and waters which could be affected by pollution if action pursuant to Article 5 NID is not taken shall be identified by the Member States in accordance with the criteria set out in Annex I NID
+
+
+
Status, trends in vulnerable zones, parts of vulnerable zones.
+
+
+
MS are requested to improve status respectively to implement measures to protect water resources or to achieve trend reversal when pollution is increasing, etc.
+
+
+
+
Nitrates Directive (91/676/EEC) – NID
+
+
4-year period report
+
+
+
(Annex V reporting)
+
+
AM
+
+
ManagementRestrictionOrRegulationZone
+
+
+
(zoneType = nitrateVulnerableZone)
+
+
To be reported: the location of the designed vulnerable zones, distinguishing between existing zones and zones designated since the previous report (map);
+
+
+
Nitrates Directive (91/676/EEC) - NID
+
MonitoringStations (ground/surface) (Article 10)
+
EF
+
EnvironmentalMonitoringFacility
+
Aggregated datasets (yearly mean, n° of sample, trend)
+
+
+
Noise Directive (2002/49/EC) - END
+
+
AM
+
+
ManagementRestrictionOrRegulationZone
+
+
+
(zoneType = noiseRestrictionZone)
+
+
+
Delimitation of areas: quiet area in an agglomeration, quiet area in open country. END applies also to areas near schools, hospitals and other noise sensitive buildings and areas. Supplementary noise indicators for quiet areas in open country.
+
+
+
Action plans should include actions which the competent authorities intend to take, including any measures to preserve quiet areas.
+
+
+
+
Noise Directive (2002/49/EC) - END
+
Noise Map
+
US
+
GovernmentalService
+
e.g "A strategic noise map is the presentation of data on one of the following aspects: <…> the estimated number of dwellings, schools and hospitals in a certain area that are exposed to specific values of a noise indicator, »
+
+
+
Urban Waste Water Treatment Directive (91/271/EEC) - UWWT
+
Situation in MS
+
AM
+
+
ManagementRestrictionOrRegulationZone
+
+
+
(zoneType = sensitiveArea)
+
+
+
Agglomerations (= municipalities),
+
+
+
Sensitive areas (= catchments),
+
+
+
Less sensitive areas
+
+
+
Other areas
+
+
+
Treatment level, treatment performance,
+
+
+
MS are requested to improve connection to waste water treatment plants if necessary
+
+
+
+
+
Water Framework Directive
+
+
+
(2000/60/EC) - WFD
+
+
River Basin District (Article 3)
+
AM
+
+
ManagementRestrictionOrRegulationZone
+
+
+
(zoneType = riverBasinDistrict);
+
+
+
specialised zone type = river basin district sub-units
+
+
Annual average pollutant concentrations (e.g. nitrates, phosphates)
+
+
+
+
Water Framework Directive
+
+
+
(2000/60/EC) - WFD
+
+
+
Administrative arrangements and coordination in terms of managing protection of inland surface waters, transitional waters,
+
+
+
coastal waters and groundwater
+
+
AM
+
+
ManagementRestrictionOrRegulationZone
+
+
+
(zoneType = riverBasinDistrict);
+
+
+
specialised zone type = river basin district sub-units
+
+
+
RBD means the area of land and sea, made up of one or more neighbouring river basins together with their associated groundwaters and coastal waters, which is identified under Article 3(1) as the main unit for management of river basins.)
+
+
+
Declaration of RBD-name (English, national), area and responsible authorities within RBD ("competent authorities"), postal address of authorities, in summary texts information about coordination and institutional relationships, especially if RBD is an international RBD
+
+
+
Declaration of SubUnits (see below) when RBD is divided into sub management units.
+
+
+
SubUnit-name (English, national), area
+
+
+
Note: Term sub-units cannot be found in text of WFD. SubUnits were introduced to have management units that are more comparable. SubUnits are sub-divisions of large RBD, small RBD’s have no SubUnits respectively SubUnit and RBD are equal.
+
+
+
+
+
Water Framework Directive
+
+
+
(2000/60/EC) - WFD
+
+
Status and objectives of inland surface waters, transitional waters, coastal waters and groundwater within each ManagementRestrictionOrRegulationZone
+
AM
+
+
ManagementRestrictionOrRegulationZone
+
+
+
(zoneType = waterBodyForWFD)
+
+
+
Annex D of AM data specification provides technical guidelines for further modelling of the water bodies for WFD (waterBodyForWFD) including the following sub-types:
+
+
+
+
+
WFD Surface waterbodies (Body of surface water means a discrete and significant element of surface water such as a lake, a reservoir, a stream, river or canal, part of a stream, river or canal, a transitional water or a stretch of coastal water.):
+
+
+
+
WFD River waterbodies
+
+
+
WFD Lake waterbodies
+
+
+
WFD Transitional waterbodies
+
+
+
WFD Coastal waterbodies
+
+
+
+
+
+
+
+
+
+
WFD Groundwaterbodies (Body of groundwater. means a distinct volume of groundwater within an aquifer or aquifers.)
+
+
+
+
+
Note: Waterbodies are also a management unit.
+
+
+
e.g. if a waterbody is whether articifial, heavily modified or natural and if waterbody will reach the environmental objectives in terms of good environmental status respectively potential (ecological, chemical and/or quantitative status/potential).
+
+
+
Status/potential is monitored respectively carried out by assessment of so called quality elements:
+
+
+
+
+
biological (composition, abundance and biomass of invertebrates etc.)
chemical and physico-chemical (heavy metals, pesticides etc.)
+
+
+
etc.
+
+
+
+
+
+
+
Water Framework Directive
+
+
+
(2000/60/EC) - WFD
+
+
+
SurfaceWaterMonitoringStation
+
+
+
GroundWaterMonitoringStation
+
+
+
Network
+
+
+
(Article 8)
+
+
EF
+
+
EnvironmentalMonitoringFacility
+
+
+
EnvironmentalMonitoringNetwork
+
+
+
ObservingCapability
+
+
+
Data is for the SoE reporting
+
+
+
+
+
Water Framework Directive
+
+
+
(2000/60/EC) - WFD
+
+
Programme (Article 8)
+
EF
+
EnvironmentalMonitoringProgram
+
Quality Elements
+
+
+
+
Water Framework Directive
+
+
+
(2000/60/EC) - WFD
+
+
WaterBodies (Article 5)
+
AM
+
+
ManagementRestrictionOrRegulationZone
+
+
+
(zoneType = waterBodyForWFD)
+
+
e.g. Indicators of good environmental status
+
+
+
+
Water Framework Directive
+
+
+
(2000/60/EC) – WFD
+
+
WFD reporting
+
SR
+
MarineCircultationArea (coastal and transitional waters)
+
to support to define and use coastal and transitional waters (also used in WFD reporting: as WFD coastal waters, WFD transitional waters)
+
+
+
+
Water Framework Directive
+
+
+
(2000/60/EC) - WFD
+
+
Economic analysis (annex II)
+
US
+
UtilityNetwork
+
+
e.g. water network & sewer network
+
+
+
Attention: UtilityNetwork has NO geometry itself: it’s just a collection of located networks elements (nodes and links).
+
+
+
+
WISE – Water Information System
+
Quality of the water
+
AM
+
+
ManagementRestrictionOrRegulationZone
+
+
+
(zoneType = waterBodyForWFD)
+
+
+
Sub-set can be defined as:
+
+
+
Main Rivers
+
+
+
Main Lakes
+
+
+
Transitional Waters
+
+
+
Coastal Waters
+
+
+
Remark:
+
+
+
Derived from geometries reported under WFD (but not for all MS).
+
+
+
These are more a kind of aggregation units or management units.
+
+
+
For example: in DE main rivers and main lakes are a selection of WFD-watercourses respectively WFD-waterbodies (catchment ≥500 km² respectively surface area ≥ 10 km²)
+
+
+
WISE-Reference datasets – in the case when they are compliant with (sub-set of) the waterBodyForWFD.:
+
+
+
EEA maps reported information to WISE Main Rivers, WISE Main Lakes, WISE Transitional waters, WISE Coastal Waters
+
+
+
+
+
+
+
G.2. Overview of legislation for the identified reporting units
+2. 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
+
+4. Surveys on unique identifiers and usage of the elements of the spatial and temporal schema,
+
+
+5. 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 Environment Agency
+
+
+6. The Thematic Working Groups have been composed of experts from Austria, Australia, Belgium, Bulgaria, Czech Republic, Denmark, Finland, France, Germany, Hungary, Ireland, Italy, Latvia, Netherlands, Norway, Poland, Romania, Slovakia, Spain, Slovenia, Sweden, Switzerland, Turkey, UK, the European Environment Agency and the European Commission.
+
+
+7. For Annex IIIII, the consultation and testing phase lasted from 20 June to 21 October 2011.
+
+11. Conceptual models related to specific areas (e.g. INSPIRE themes)
+
+
+12. In the case of the Annex IIIII data specifications, the extracted requirements are used to formulate an amendment to the existing Implementing Rule.
+
+
+
\ No newline at end of file
diff --git a/data/am/dataspecification_am.pdf b/data/am/dataspecification_am.pdf
new file mode 100644
index 00000000..81dbb0e3
Binary files /dev/null and b/data/am/dataspecification_am.pdf differ
diff --git a/data/au/dataspecification_au.html b/data/au/dataspecification_au.html
index 2f343fa6..0c07746f 100644
--- a/data/au/dataspecification_au.html
+++ b/data/au/dataspecification_au.html
@@ -464,7 +464,7 @@
For the exchange and classification of spatial objects from data sets meeting the conditions laid down in Article 4 of Directive 2007/2/EC, Member States shall use the spatial object types and associated data types, enumerations and code lists that are defined in Annexes II, III and IV for the themes the data sets relate to.
+
For the exchange and classification of spatial objects from data sets meeting the conditions laid down in Article 4 of Directive 2007/2/EC, Member States shall use the spatial object types and associated data types and code lists that are defined in Annexes II, III and IV for the themes the data sets relate to.
-
Spatial object types and data types shall comply with the definitions and constraints and include the attributes and association roles set out in the Annexes.
-
-
-
The enumerations and code lists used in attributes or association roles of spatial object types or data types shall comply with the definitions and include the values set out in Annex II. The enumeration and code list values are uniquely identified by language-neutral mnemonic codes for computers. The values may also include a language-specific name to be used for human interaction.
+
When exchanging spatial objects, Member States shall comply with the definitions and constraints set out in the Annexes and provide values for all attributes and association roles set out for the relevant spatial object types and data types in the Annexes. For voidable attributes and association roles for which no value exists, Member States may omit the value.
@@ -1536,11 +1532,6 @@
5.2.1.2. Stereotypes
A structured data type without identity where exactly one of the properties of the type is present in any instance.
-
enumeration
-
Class
-
An enumeration.
-
-
codelist
Class
A code list.
@@ -1634,54 +1625,12 @@
5.2.2. Voidable characteristics
-
5.2.3. 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
-Article 6
-Code Lists and Enumerations
-
-
-
(…)
-
-
-
-
-
Attributes or association roles of spatial object types or data types that have an enumeration type may only take values from the lists specified for the enumeration type."
-
-
-
-
-
-
-
-
-
-
5.2.4. Code lists
+
5.2.3. Code lists
Code lists are modelled as classes in the application schemas. Their values, however, are managed outside of the application schema.
-
5.2.4.1. Code list types
+
5.2.3.1. Code list types
The IRs distinguish the following types of code lists.
@@ -1695,32 +1644,44 @@
5.2.4.1. Code list types
IR Requirement Article 6
-Code Lists and Enumerations
+Code Lists for Spatial Data Sets
-
Code lists shall be of one of the following types, as specified in the Annexes:
-
-
+
The code lists included in this Regulation set out the multilingual thesauri to be used for the key attributes, in accordance with Article 8(2), point (c), of Directive 2007/2/EC.
+
-
a) code list whose allowed values comprise only the values specified in this Regulation;
+
The Commission shall establish and operate an INSPIRE code list register at Union level for managing and making publicly available the values that are included in the code lists referred to in paragraph 1.
-
b) code lists whose allowed values comprise the values specified in this Regulation and narrower values defined by data providers;
+
The Commission shall be assisted by the INSPIRE Commission expert group in the maintenance and update of the code list values.
-
c) code lists whose allowed values comprise the values specified in this Regulation and additional values at any level defined by data providers;
+
Code lists shall be one of the following types:
+
+
+
+
code lists whose values comprise only the values specified in the INSPIRE code list register;
-
d) code lists, whose allowed values comprise any values defined by data providers.
-
-
For the purposes of points (b), (c) and (d), in addition to the allowed values, data providers may use the values specified in the relevant INSPIRE Technical Guidance document available on the INSPIRE web site of the Joint Research Centre.
-
+
code lists whose values comprise the values specified in the INSPIRE code list register and narrower values defined by data providers;
-
+
+
code lists whose values comprise the values specified in the INSPIRE code list register and additional values at any level defined by data providers;
+
+
+
code lists, whose values comprise any values defined by data providers.
+
+
+
+
Code lists may be hierarchical. Values of hierarchical code lists may have a more general parent value.
+
+
+
Where, for an attribute whose type is a code list as referred to in paragraph 4, points (b), (c) or (d), a data provider provides a value that is not specified in the INSPIRE code list register, that value and its definition and label shall be made available in another register.
+
@@ -1767,7 +1728,7 @@
5.2.4.1. Code list types
NOTE This data specification may specify recommended values for some of the code lists of type (b), (c) and (d) (see section 5.2.4.3). These recommended values are specified in a dedicated Annex.
-
In addition, code lists can be hierarchical, as explained in Article 6(2) of the IRs.
+
In addition, code lists can be hierarchical, as explained in Article 6(5) of the IRs.
@@ -1779,15 +1740,15 @@
5.2.4.1. Code list types
IR Requirement Article 6
-Code Lists and Enumerations
+Code Lists for Spatial Data Sets
(…)
-
+
-
Code lists may be hierarchical. Values of hierarchical code lists may have a more generic parent value. Where the valid values of a hierarchical code list are specified in a table in this Regulation, the parent values are listed in the last column.
+
Code lists may be hierarchical. Values of hierarchical code lists may have a more general parent value.
@@ -1800,7 +1761,7 @@
5.2.4.1. Code list types
-
5.2.4.2. Obligations on data providers
+
5.2.3.2. Obligations on data providers
@@ -1811,18 +1772,15 @@
5.2.4.2. Obligations on data providers
IR Requirement Article 6
-Code Lists and Enumerations
+Code Lists for Spatial Data Sets
(….)
-
-
-
Where, for an attribute whose type is a code list as referred to in points (b), (c) or (d) of paragraph 1, a data provider provides a value that is not specified in this Regulation, that value and its definition shall be made available in a register.
-
+
-
Attributes or association roles of spatial object types or data types whose type is a code list may only take values that are allowed according to the specification of the code list.
+
Where, for an attribute whose type is a code list as referred to in paragraph 4, points (b), (c) or (d), a data provider provides a value that is not specified in the INSPIRE code list register, that value and its definition and label shall be made available in another register.
@@ -1831,17 +1789,17 @@
5.2.4.2. Obligations on data providers
-
Article 6(4) obliges data providers to use only values that are allowed according to the specification of the code list. The "allowed values according to the specification of the code list" are the values explicitly defined in the IRs plus (in the case of code lists of type (b), (c) and (d)) additional values defined by data providers.
+
Article 6(6) obliges data providers to use only values that are allowed according to the specification of the code list. The "allowed values according to the specification of the code list" are the values explicitly defined in the IRs plus (in the case of code lists of type (b), (c) and (d)) additional values defined by data providers.
-
For attributes whose type is a code list of type (b), (c) or (d) data providers may use additional values that are not defined in the IRs. Article 6(3) requires that such additional values and their definition be made available in a register. This enables users of the data to look up the meaning of the additional values used in a data set, and also facilitates the re-use of additional values by other data providers (potentially across Member States).
+
For attributes whose type is a code list of type (b), (c) or (d) data providers may use additional values that are not defined in the IRs. Article 6(6) requires that such additional values and their definition be made available in a register. This enables users of the data to look up the meaning of the additional values used in a data set, and also facilitates the re-use of additional values by other data providers (potentially across Member States).
NOTE Guidelines for setting up registers for additional values and how to register additional values in these registers is still an open discussion point between Member States and the Commission.
-
5.2.4.3. Recommended code list values
+
5.2.3.3. Recommended code list values
For code lists of type (b), (c) and (d), this data specification may propose additional values as a recommendation (in a dedicated Annex). These values will be included in the INSPIRE code list register. This will facilitate and encourage the usage of the recommended values by data providers since the obligation to make additional values defined by data providers available in a register (see section 5.2.4.2) is already met.
@@ -1867,7 +1825,7 @@
5.2.4.3. Recommended code list values
-
5.2.4.4. Governance
+
5.2.3.4. Governance
The following two types of code lists are distinguished in INSPIRE:
@@ -1935,7 +1893,7 @@
5.2.4.4. Governance
-
5.2.4.5. Vocabulary
+
5.2.3.5. Vocabulary
For each code list, a tagged value called "vocabulary" is specified to define a URI identifying the values of the code list. For INSPIRE-governed code lists and externally governed code lists that do not have a persistent identifier, the URI is constructed following the pattern http://inspire.ec.europa.eu/codelist/<UpperCamelCaseName>;.
@@ -1948,7 +1906,7 @@
5.2.4.5. Vocabulary
-
5.2.5. Consistency between spatial data sets
+
5.2.4. Consistency between spatial data sets
Administrative units and maritime zones will very likely be used in conjunction with data coming from other INSPIRE themes (e.g. cadastral parcels, orthoimagery, statistical units, sea regions). Administrative units and maritime zones should be considered as reference data, and geometric consistency with other themes may be achieved if these other themes use administrative units or maritime zones as background data during the production or the validation of their own data.
@@ -1957,7 +1915,7 @@
5.2.5. Consistency between spati
-
5.2.6. Identifier management
+
5.2.5. Identifier management
@@ -2001,7 +1959,7 @@
5.2.6. Identifier management
-
5.2.7. Geometry representation
+
5.2.6. Geometry representation
@@ -2033,7 +1991,7 @@
5.2.7. Geometry representation
-
5.2.8. Temporality representation
+
5.2.7. Temporality representation
The application schema(s) use(s) the derived attributes "beginLifespanVersion" and "endLifespanVersion" to record the lifespan of a spatial object.
@@ -2646,10 +2604,10 @@
5.4.1.5.1. Flat model of bound
Finally, the following associations between boundaries and administrative units have to be built:
-
+
-
-
+
+
@@ -2896,10 +2854,10 @@
5.4.1.5.2. Multi-layer
Finally, the following associations between boundaries and administrative units have to be built:
-
+
-
-
+
+
@@ -4331,16 +4289,16 @@
5.4.2.2.1. ResidenceOfAuthority
-
5.4.2.3. Enumerations
+
5.4.2.3. Code lists
-
5.4.2.3.1. LegalStatusValue
+
5.4.2.3.1. AdministrativeHierarchyLevel
-
LegalStatusValue
+
AdministrativeHierarchyLevel
@@ -4353,51 +4311,23 @@
5.4.2.3.1. LegalStatusValue
Name:
-
legal status value
+
administrative hierarchy level
Definition:
-
Description of the legal status of administrative boundaries.
-
-
-
URI:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Value:
-
agreed
+
Levels of administration in the national administrative hierarchy. This code list reflects the level in the hierarchical pyramid of the administrative structures, which is based on geometric aggregation of territories and does not necessarily describe the subordination between the related administrative authorities.
-
Definition:
-
The edge-matched boundary has been agreed between neighbouring administrative units and is stable now.
The boundaries of neighbouring administrative units do not have the same set of coordinates.
+
Values:
+
The allowed values for this code list comprise only the values specified in the INSPIRE Registry.
@@ -4478,18 +4380,15 @@
5.4.2.3.2. TechnicalStatusValue
-
-
-
5.4.2.4. Code lists
-
5.4.2.4.1. AdministrativeHierarchyLevel
+
5.4.2.3.3. TechnicalStatusValue
-
AdministrativeHierarchyLevel
+
TechnicalStatusValue
@@ -4502,11 +4401,11 @@
5.4.2.4.1. AdministrativeHierarchyLev
Name:
-
administrative hierarchy level
+
technical status value
Definition:
-
Levels of administration in the national administrative hierarchy. This code list reflects the level in the hierarchical pyramid of the administrative structures, which is based on geometric aggregation of territories and does not necessarily describe the subordination between the related administrative authorities.
+
Description of the technical status of administrative boundaries.
The allowed values for this code list comprise only the values specified in Annex C .
+
The allowed values for this code list comprise only the values specified in the INSPIRE Registry.
@@ -4528,12 +4427,12 @@
5.4.2.4.1. AdministrativeHierarchyLev
-
5.4.2.5. Imported types (informative)
+
5.4.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.
+
This section lists definitions for feature types, data types and code lists that are defined in other application schemas. The section is purely informative and should help the reader understand the feature catalogue presented in the previous sections. For the normative documentation of these types, see the given references.
-
5.4.2.5.1. CharacterString
+
5.4.2.4.1. CharacterString
@@ -4566,7 +4465,7 @@
5.4.2.5.1. CharacterString
-
5.4.2.5.2. CountryCode
+
5.4.2.4.2. CountryCode
@@ -4599,7 +4498,7 @@
5.4.2.5.2. CountryCode
-
5.4.2.5.3. DateTime
+
5.4.2.4.3. DateTime
@@ -4632,7 +4531,7 @@
5.4.2.5.3. DateTime
-
5.4.2.5.4. GM_Curve
+
5.4.2.4.4. GM_Curve
@@ -4665,7 +4564,7 @@
5.4.2.5.4. GM_Curve
-
5.4.2.5.5. GM_MultiSurface
+
5.4.2.4.5. GM_MultiSurface
@@ -4698,7 +4597,7 @@
5.4.2.5.5. GM_MultiSurface
-
5.4.2.5.6. GM_Point
+
5.4.2.4.6. GM_Point
@@ -4731,7 +4630,7 @@
5.4.2.5.6. GM_Point
-
5.4.2.5.7. GeographicalName
+
5.4.2.4.7. GeographicalName
@@ -4768,7 +4667,7 @@
5.4.2.5.7. GeographicalName
-
5.4.2.5.8. Identifier
+
5.4.2.4.8. Identifier
@@ -4813,7 +4712,7 @@
5.4.2.5.8. Identifier
-
5.4.2.5.9. LocalisedCharacterString
+
5.4.2.4.9. LocalisedCharacterString
@@ -6109,7 +6008,7 @@
5.5.2.3.1. BaselineSegmentTypeValue<
Values:
-
The allowed values for this code list comprise only the values specified in Annex C .
+
The allowed values for this code list comprise only the values specified in the INSPIRE Registry.
@@ -6154,7 +6053,7 @@
5.5.2.3.2. MaritimeZoneTypeValue
Values:
-
The allowed values for this code list comprise only the values specified in Annex C .
+
The allowed values for this code list comprise only the values specified in the INSPIRE Registry.
@@ -6166,7 +6065,7 @@
5.5.2.3.2. MaritimeZoneTypeValue
5.5.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.
+
This section lists definitions for feature types, data types and code lists that are defined in other application schemas. The section is purely informative and should help the reader understand the feature catalogue presented in the previous sections. For the normative documentation of these types, see the given references.
5.5.2.4.1. CountryCode
@@ -6664,7 +6563,7 @@
6.1.1.2. Coordinate reference systems
-
Other coordinate reference systems may be specified for specific spatial data themes in this Annex.
+
Other coordinate reference systems may be specified for specific spatial data themes.
For regions outside of continental Europe, Member States may define suitable coordinate reference systems.
@@ -6672,7 +6571,8 @@
6.1.1.2. Coordinate reference systems
-
The geodetic codes and parameters needed to describe these coordinate reference systems and to allow conversion and transformation operations shall be documented and an identifier shall be created, according to EN ISO 19111 and ISO 19127.
+
The geodetic codes and parameters needed to describe these other coordinate reference systems and to allow conversion and transformation operations shall be documented and an identifier shall be created in a coordinate systems register established and operated by the Commission, according to EN ISO 19111 and ISO 19127.
+The Commission shall be assisted by the INSPIRE Commission expert group in the maintenance and update of the coordinate systems register.
@@ -6690,7 +6590,7 @@
6.1.1.3. Display
IR Requirement
-Annex II, Section 1.4
+Annex II, Section 1.5 Coordinate Reference Systems used in the View Network Service
@@ -6712,7 +6612,7 @@
6.1.1.4. Identifiers for
IR Requirement
-Annex II, Section 1.4
+Annex II, Section 1.5 Coordinate Reference Systems used in the View Network Service
@@ -6730,7 +6630,7 @@
6.1.1.4. Identifiers for
-
These Technical Guidelines propose to use the http URIs provided by the Open Geospatial Consortium as coordinate reference system identifiers (see identifiers for the default CRSs below). These are based on and redirect to the definition in the EPSG Geodetic Parameter Registry (http://www.epsg-registry.org/).
+
These Technical Guidelines propose to use the http URIs provided by the Open Geospatial Consortium as coordinate reference system identifiers (see identifiers for the default CRSs in the INSPIRE coordinate reference systems register). These are based on and redirect to the definition in the EPSG Geodetic Parameter Registry (http://www.epsg-registry.org/).
@@ -6743,7 +6643,7 @@
6.1.1.4. Identifiers for
TG Requirement 2
-
The identifiers listed in Table 2 shall be used for referring to the coordinate reference systems used in a data set.
+
The identifiers listed in the INSPIRE coordinate reference systems register (https://inspire.ec.europa.eu/crs) shall be used for referring to the coordinate reference systems used in a data set.
@@ -6765,130 +6665,6 @@
6.1.1.4. Identifiers for
-
-
Table 2. http URIs for the default coordinate reference systems
8.3.2.1. Guidelines for reporting quantitative results of the data quality evaluation
-
+
-
-
+
+
@@ -9136,10 +8912,10 @@
8.3.2.2. Guidelines for reporting descriptive results of the Data Quality evaluation
-
+
-
-
+
+
@@ -9315,15 +9091,14 @@
9.3. Encodings
Article 7 Encoding
-
-
-
-
Every encoding rule used to encode spatial data shall conform to EN ISO 19118. In particular, it shall specify schema conversion rules for all spatial object types and all attributes and association roles and the output data structure used.
-
-
-
Every encoding rule used to encode spatial data shall be made available.
-
-
+
+
1. Every encoding rule used to encode spatial data shall conform to EN ISO 19118. In particular, it shall specify schema conversion rules for all spatial object types and all attributes and association roles and the output data structure used.
+
+
+
2. Every encoding rule used to encode spatial data shall be made available.
+
+
+
2a. Every encoding rule used to encode spatial data shall also specify whether and how to represent attributes and association roles for which a corresponding value exists but is not contained in the spatial data sets maintained by a Member State, or cannot be derived from existing values at reasonable costs.
@@ -9809,10 +9584,10 @@
11.1.1. Layers organisation
11.2. Styles required to be supported by INSPIRE view services
11.2.1. Styles for the layer AU.AdministrativeUnit
-
+
-
-
+
+
@@ -9883,10 +9658,10 @@
11.2.1. Styles for the laye
11.2.2. Styles for the layer AU.AdministrativeBoundary
-
+
-
-
+
+
@@ -9958,10 +9733,10 @@
11.2.2. Styles for the
11.2.3. Styles for the layer AU.Condominium
-
+
-
-
+
+
@@ -10032,10 +9807,10 @@
11.2.3. Styles for the layer AU.Co
11.2.4. Styles for the layer AU.Baseline
-
+
-
-
+
+
@@ -10108,10 +9883,10 @@
11.2.4. Styles for the layer AU.Basel
11.2.5. Styles for the layer AU.MaritimeBoundary
-
+
-
-
+
+
@@ -10181,10 +9956,10 @@
11.2.5. Styles for the layer
11.2.6. Styles for the layer AU.ContiguousZone
-
+
-
-
+
+
@@ -10259,10 +10034,10 @@
11.2.6. Styles for the layer AU
11.2.7. Styles for the layer AU.ContinentalShelf
-
+
-
-
+
+
@@ -10334,10 +10109,10 @@
11.2.7. Styles for the layer
11.2.8. Styles for the layer AU.ExclusiveEconomicZone
-
+
-
-
+
+
@@ -10416,10 +10191,10 @@
11.2.8. Styles for the l
11.2.9. Styles for the layer AU.InternalWaters
-
+
-
-
+
+
@@ -10498,10 +10273,10 @@
11.2.9. Styles for the layer AU
11.2.10. Styles for the layer AU.TerritorialSea
-
+
-
-
+
+
@@ -10950,7 +10725,7 @@
Annex A: Abstract Test Suite - (normativ
all the spatial object / data types that have corresponding types in the source dataset after the necessary transformations fulfil the requirements set out in the ISDSS Regulation and
-
all additional elements of the source model (spatial object types, data types, attributes, constraints, code lists and enumerations together with their values) do not conflict with any rule defined in the interoperability target specifications defined for any theme within INSPIRE.
+
all additional elements of the source model (spatial object types, data types, attributes, constraints and code lists together with their values) do not conflict with any rule defined in the interoperability target specifications defined for any theme within INSPIRE.
@@ -11010,7 +10785,7 @@
A.1.1. Schema element denomination te
b) Reference: Art. 3 and Art.4 of Commission Regulation No 1089/2010
-
c) Test method: Examine whether the corresponding elements of the source schema (spatial object types, data types, attributes, association roles, code lists, and enumerations) are mapped to the target schema with the correct designation of mnemonic names.
+
c) Test method: Examine whether the corresponding elements of the source schema (spatial object types, data types, attributes, association roles and code lists) are mapped to the target schema with the correct designation of mnemonic names.
NOTE Further technical information is in the Feature catalogue and UML diagram of the application schema(s) in section 5.2.
@@ -11028,7 +10803,7 @@
A.1.2. Value type test
c) Test method: Examine whether the value type of each provided attribute or association role adheres to the corresponding value type specified in the target specification.
-
NOTE 1 This test comprises testing the value types of INSPIRE identifiers, the value types of attributes and association roles that should be taken from enumeration and code lists, and the coverage domains.
+
NOTE 1 This test comprises testing the value types of INSPIRE identifiers, the value types of attributes and association roles that should be taken from code lists, and the coverage domains.
NOTE 2 Further technical information is in the Feature catalogue and UML diagram of the application schema(s) in section 5.2.
@@ -11037,20 +10812,17 @@
A.1.2. Value type test
A.1.3. Value test
-
a) Purpose: Verify whether all attributes or association roles whose value type is a code list or enumeration take the values set out therein.
+
a) Purpose: Verify whether all attributes or association roles whose value type is a code list take the values set out therein.
b) Reference: Art.4 (3) of Commission Regulation No 1089/2010.
-
c) Test method: When an attribute / association role has an enumeration or code list as its type, compare the values of each instance with those provided in the application schema. To pass this tests any instance of an attribute / association role
+
c) Test method: When an attribute / association role has a code list as its type, compare the values of each instance with those provided in the application schema. To pass this tests any instance of an attribute / association role
-
shall not take any other value than defined in the enumeration table when its type is an enumeration.
-
-
shall take only values explicitly specified in the code list when the code list’s extensibility is "none".
@@ -11062,10 +10834,10 @@
A.1.3. Value test
NOTE 2 When a data provider only uses code lists with narrower (more specific values) this test can be fully performed based on internal information.
-
NOTE 3 This test is applicable to all application schemas to verify whether each instance of the legalStatus attribute takes only the values specified in the LegalStatusValue enumeration.
+
NOTE 3 This test is applicable to all application schemas to verify whether each instance of the legalStatus attribute takes only the values specified in the LegalStatusValue code list.
-
NOTE 4 This test is applicable to all application schemas to verify whether each instance of the technicalStatus attribute takes only the values specified in the TechnicalStatusValue enumeration.
+
NOTE 4 This test is applicable to all application schemas to verify whether each instance of the technicalStatus attribute takes only the values specified in the TechnicalStatusValue code list.
NOTE 5 This test is applicable to the code list specified in the AdministrativeUnits application schema to verify whether:
@@ -11633,7 +11405,7 @@
A.8.2. CRS http URI test
a) Purpose: Verify whether the coordinate reference system used to deliver data for INSPIRE network services has been identified by URIs according to the EPSG register.
-
b) Reference: Table 2 in Section 6 of this technical guideline
+
b) Reference: Section 6 of this technical guideline
c) Test method: Compare the URI of the dataset with the URIs in the table.
@@ -12100,140 +11872,7 @@
C.1. INSPIRE Applicatio
Values:
-
The allowed values for this code list comprise only the values specified in the table below.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
1stOrder
-
-
-
-
-
-
-
-
-
Name:
-
1st order
-
-
-
Definition:
-
Highest level in the national administrative hierarchy (country level).
-
-
-
-
-
-
-
2ndOrder
-
-
-
-
-
-
-
-
-
Name:
-
2nd order
-
-
-
Definition:
-
2nd level in the national administrative hierarchy.
-
-
-
-
-
-
-
3rdOrder
-
-
-
-
-
-
-
-
-
Name:
-
3rd order
-
-
-
Definition:
-
3rd level in the national administrative hierarchy.
-
-
-
-
-
-
-
4thOrder
-
-
-
-
-
-
-
-
-
Name:
-
4th order
-
-
-
Definition:
-
4th level in the national administrative hierarchy.
-
-
-
-
-
-
-
5thOrder
-
-
-
-
-
-
-
-
-
Name:
-
5th order
-
-
-
Definition:
-
5th level in the national administrative hierarchy.
-
-
-
-
-
-
-
6thOrder
-
-
-
-
-
-
-
-
-
Name:
-
6th order
-
-
-
Definition:
-
6th level in the national administrative hierarchy.
+
The allowed values for this code list comprise only the values specified in the INSPIRE Registry.
@@ -12294,77 +11933,7 @@
C.2. INSPIRE Application Sche
Values:
-
The allowed values for this code list comprise only the values specified in the table below.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
normal
-
-
-
-
-
-
-
-
-
Name:
-
normal
-
-
-
Definition:
-
The normal baseline for measuring the breadth of the territorial sea is the low-water line along the coast as marked on large-scale charts officially recognized by the coastal State.
-
-
-
-
-
-
-
straight
-
-
-
-
-
-
-
-
-
Name:
-
straight
-
-
-
Definition:
-
The baseline for measuring the breadth of the territorial sea is the straight baseline established by joining the appropriate points.
-
-
-
-
-
-
-
archipelagic
-
-
-
-
-
-
-
-
-
Name:
-
archipelagic
-
-
-
Definition:
-
The baseline for measuring the breadth of the territorial sea is the straight baseline joining the outermost points of the outermost islands and drying reefs of the archipelago.
+
The allowed values for this code list comprise only the values specified in the INSPIRE Registry.
@@ -12380,10 +11949,10 @@
C.2. INSPIRE Application Sche
-
+
-
-
+
+
@@ -12406,119 +11975,7 @@
C.2. INSPIRE Application Sche
Values:
-
The allowed values for this code list comprise only the values specified in the table below.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
internalWaters
-
-
-
-
-
-
-
-
-
Name:
-
Internal Waters
-
-
-
Definition:
-
The waters on the landward side of the baselines of the territorial sea of the coastal State.
-
-
-
-
-
-
-
territorialSea
-
-
-
-
-
-
-
-
-
Name:
-
Territorial Sea
-
-
-
Definition:
-
A belt of sea of a defined breadth not exceeding 12 nautical miles measured from the baselines determined in accordance to the United Nations Convention of Law on the Sea.
-
-
-
-
-
-
-
contiguousZone
-
-
-
-
-
-
-
-
-
Name:
-
Contiguous Zone
-
-
-
Definition:
-
A zone contiguous to a territorial sea of a coastal State, which may not extend beyond 24 nautical miles from the baselines from which the breadth of the territorial sea is measured.
-
-
-
-
-
-
-
exclusiveEconomicZone
-
-
-
-
-
-
-
-
-
Name:
-
Exclusive Economic Zone
-
-
-
Definition:
-
An area beyond and adjacent to the territorial sea of a coastal State, subject to the specific legal regime under which the rights and jurisdiction of the coastal State and the rights and freedoms of other States are governed by the relevant provisions of the United Nations Convention on Law of the Sea.
-
-
-
-
-
-
-
continentalShelf
-
-
-
-
-
-
-
-
-
Name:
-
Continental Shelf
-
-
-
Definition:
-
A maritime zone beyond and adjacent to the a territorial sea of a coastal State whose outer boundary is determined in accordance with Article 76 of the United Nations Convention on the Law of the Sea.
+
The allowed values for this code list comprise only the values specified in the INSPIRE Registry.
diff --git a/data/au/dataspecification_au.pdf b/data/au/dataspecification_au.pdf
index 45e02216..db102101 100644
Binary files a/data/au/dataspecification_au.pdf and b/data/au/dataspecification_au.pdf differ
diff --git a/data/bu/dataspecification_bu.html b/data/bu/dataspecification_bu.html
new file mode 100644
index 00000000..79bed074
--- /dev/null
+++ b/data/bu/dataspecification_bu.html
@@ -0,0 +1,36877 @@
+
+
+
+
+
+
+
+
+
+
+
+D2.8.III.2 Data Specification on Buildings – Technical Guidelines
+
+
+
+
+
+
+
+
+
+
+
+
+
+
INSPIREInfrastructure for Spatial Information in Europe
+
+
D2.8.III.2 Data Specification on Buildings – Technical Guidelines
+
+
+
+
+
+
+
+
Title
+
D2.8.III.2 Data Specification on Buildings – Technical Guidelines
+
+
+
Creator
+
Temporary MIWP 2021-2024 sub-group 2.3.1
+
+
+
Date of publication
+
2024-01-31
+
+
+
Subject
+
INSPIRE Data Specification for the spatial data theme Buildings
+
+
+
Publisher
+
INSPIRE Maintenance and Implementation Group (MIG)
+
+
+
Type
+
Text
+
+
+
Description
+
This document describes the INSPIRE Data Specification for the spatial data theme Buildings
Directive 2007/2/EC of the European Parliament and of the Council of 14 March 2007 establishing an Infrastructure for Spatial Information in the European Community (INSPIRE)
+
+
+
+
+
Foreword
+
How to read the document?
+
+
This document describes the "INSPIRE data specification on Buildings – Technical Guidelines" version 3.0 as developed by the Thematic Working Group (TWG) BU using both natural and a conceptual schema language.
+
+
+
The data specification is based on a common template[1] used for all data specifications, which has been harmonised using the experience from the development of the Annex I, II and III data specifications.
+
+
+
This document provides guidelines for the implementation of the provisions laid down in the draft Implementing Rule for spatial data sets and services of the INSPIRE Directive. It also includes additional requirements and recommendations that, although not included in the Implementing Rule, are relevant to guarantee or to increase data interoperability.
+
+
+
Two executive summaries provide a quick overview of the INSPIRE data specification process in general, and the content of the data specification on Buildings in particular. We highly recommend that managers, decision makers, and all those new to the INSPIRE process and/or information modelling should read these executive summaries first.
+
+
+
The UML diagrams (in Chapter 5) offer a rapid way to see the main elements of the specifications and their relationships. The definition of the spatial object types, attributes, and relationships are included in the Feature Catalogue (also in Chapter 5). People having thematic expertise but not familiar with UML can fully understand the content of the data model focusing on the Feature Catalogue. Users might also find the Feature Catalogue especially useful to check if it contains the data necessary for the applications that they run. The technical details are expected to be of prime interest to those organisations that are responsible for implementing INSPIRE within the field of Buildings, but also to other stakeholders and users of the spatial data infrastructure.
+
+
+
The technical provisions and the underlying concepts are often illustrated by examples. Smaller examples are within the text of the specification, while longer explanatory examples and descriptions of selected use cases are attached in the annexes.
+
+
+
In order to distinguish the INSPIRE spatial data themes from the spatial object types, the INSPIRE spatial data themes are written in italics.
+
+
+
+
+
+
+
+
The document will be publicly available as a 'non-paper'. It does not represent an official position of the European Commission, and as such cannot be invoked in the context of legal procedures.
+
+
+
+
+
Legal Notice
+
+
+
Neither the European Commission nor any person acting on behalf of the Commission is responsible for the use which might be made of this publication.
+
+
+
Interoperability of Spatial Data Sets and Services – General Executive Summary
+
+
The challenges regarding the lack of availability, quality, organisation, accessibility, and sharing of spatial information are common to a large number of policies and activities and are experienced across the various levels of public authority in Europe. In order to solve these problems it is necessary to take measures of coordination between the users and providers of spatial information. The Directive 2007/2/EC of the European Parliament and of the Council adopted on 14 March 2007 aims at establishing an Infrastructure for Spatial Information in the European Community (INSPIRE) for environmental policies, or policies and activities that have an impact on the environment.
+
+
+
INSPIRE is based on the infrastructures for spatial information that are created and maintained by the Member States. To support the establishment of a European infrastructure, Implementing Rules addressing the following components of the infrastructure have been specified: metadata, interoperability of spatial data sets (as described in Annexes I, II, III of the Directive) and spatial data services, network services, data and service sharing, and monitoring and reporting procedures.
+
+
+
INSPIRE does not require collection of new data. However, after the period specified in the Directive[2] Member States have to make their data available according to the Implementing Rules.
+
+
+
Interoperability in INSPIRE means the possibility to combine spatial data and services from different sources across the European Community in a consistent way without involving specific efforts of humans or machines. It is important to note that "interoperability" is understood as providing access to spatial data sets through network services, typically via Internet. Interoperability may be achieved by either changing (harmonising) and storing existing data sets or transforming them via services for publication in the INSPIRE infrastructure. It is expected that users will spend less time and efforts on understanding and integrating data when they build their applications based on data delivered in accordance with INSPIRE.
+
+
+
In order to benefit from the endeavours of international standardisation bodies and organisations established under international law their standards and technical means have been utilised and referenced, whenever possible.
+
+
+
To facilitate the implementation of INSPIRE, it is important that all stakeholders have the opportunity to participate in specification and development. For this reason, the Commission has put in place a consensus building process involving data users, and providers together with representatives of industry, research and government. These stakeholders, organised through Spatial Data Interest Communities (SDIC) and Legally Mandated Organisations (LMO)[3], have provided reference materials, participated in the user requirement and technical[4] surveys, proposed experts for the Data Specification Drafting Team[5], the Thematic Working Groups[6] and other ad-hoc cross-thematic technical groups and participated in the public stakeholder consultations on draft versions of the data specifications. These consultations covered expert reviews as well as feasibility and fitness-for-purpose testing of the data specifications[7].
+
+
+
This open and participatory approach was successfully used during the development of the data specifications on Annex I, II and III data themes as well as during the preparation of the Implementing Rule on Interoperability of Spatial Data Sets and Services[8] for Annex I spatial data themes and of its amendment regarding the themes of Annex II and III.
+
+
+
The development framework elaborated by the Data Specification Drafting Team aims at keeping the data specifications of the different themes coherent. It summarises the methodology to be used for the development of the data specifications, providing a coherent set of requirements and recommendations to achieve interoperability. The pillars of the framework are the following technical documents[9]:
+
+
+
+
+
The Definition of Annex Themes and Scope 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 Model 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, some common code lists, etc. Those requirements of the Generic Conceptual Model that are directly implementable are included in the Implementing Rule on Interoperability of Spatial Data Sets and Services.
+
+
+
The Methodology for the Development of Data Specifications 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 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 Common data models are a set of documents that specify data models that are referenced by a number of different data specifications. These documents include generic data models for networks, coverages and activity complexes.
+
+
+
+
+
The structure of the data specifications is based on the "ISO 19131 Geographic information - Data product specifications" standard. They include the technical documentation of the application schema, the spatial object types with their properties, and other specifics of the spatial data themes using natural language as well as a formal conceptual schema language[10].
+
+
+
A consolidated model repository, feature concept dictionary, and glossary are being maintained to support the consistent specification development and potential further reuse of specification elements. The consolidated model consists of the harmonised models of the relevant standards from the ISO 19100 series, the INSPIRE Generic Conceptual Model, and the application schemas[11] developed for each spatial data theme. The multilingual INSPIRE Feature Concept Dictionary contains the definition and description of the INSPIRE themes together with the definition of the spatial object types present in the specification. The INSPIRE Glossary defines all the terms (beyond the spatial object types) necessary for understanding the INSPIRE documentation including the terminology of other components (metadata, network services, data sharing, and monitoring).
+
+
+
By listing a number of requirements and making the necessary recommendations, the data specifications enable full system interoperability across the Member States, within the scope of the application areas targeted by the Directive. The data specifications (in their version 3.0) are published as technical guidelines and provide the basis for the content of the Implementing Rule on Interoperability of Spatial Data Sets and Services[12]. The content of the Implementing Rule is extracted from the data specifications, considering short- and medium-term feasibility as well as cost-benefit considerations. The requirements included in the Implementing Rule are legally binding for the Member States according to the timeline specified in the INSPIRE Directive.
+
+
+
In addition to providing a basis for the interoperability of spatial data in INSPIRE, the data specification development framework and the thematic data specifications can be reused in other environments at local, regional, national and global level contributing to improvements in the coherence and interoperability of data in spatial data infrastructures.
+
+
+
Buildings – Executive Summary
+
+
This document presents spatial data specification for European data related to the theme "Buildings".
+
+
+
Use cases
+
+
+
Building data is a key theme for environmental studies. On one hand, buildings are the places where people live, work and spend more of their time and where they should be ensured good quality of habitat and protection from risks (flood, fire, earthquake, …) and from pollutions (noise, air pollution, …). Buildings by themselves may deserve protection because of their historical or architectural interest. On the other hand, buildings and their inhabitants are consuming natural resources (heating, land, transport, construction material) and there is clear need to promote more sustainable buildings and to control urban spreading. This data specification addresses requirements related to European reporting, such as the Noise Directive, the Air Quality Directive, the Energy Performance of Building Directive and the Population and Housing Census Directive. The Flood Directive and the project of Soil Directive have also been taken into account.
+
+
+
Moreover, theme Buildings is part of the reference data that is required in a Spatial Data Infrastructure to describe the landscape and for lots of mapping and communication applications. Especially, some specific buildings and constructions are valuable landmarks for travellers.
+
+
+
Scope - Relations with other themes
+
+
+
The spatial features under the scope of this document are local scale spatial features such as buildings (of course) and also some other constructions of major interest for environmental applications, such as elevated constructions or environmental barriers. Spatial features representing building components are also under the scope of this document – they allow very detailed representations of different kinds of building components and ancillary constructions.
+
+
+
Other building related features at a coarser level of detail such as building groups and complexes, built-up areas, urban block, city districts, etc. are not under the scope of this document. Built-up areas and settlements may be found in themes land use, land cover and/or geographical names.
+
+
+
This document mainly focuses on the physical description of real world entities seen as constructions. An important characteristic of buildings is their capability to provide services. Because this information is covered by other INSPIRE themes related to facilities (utility and governmental services, production and industrial facilities, agricultural and aquacultural facilities), this data specification only provides a simplified classification of building services. Furthermore, building theme classes share relations with addresses, cadastral parcels and geographical names themes.
+
+
+
Existing data and standards
+
+
+
There are nowadays many datasets describing building related features. These datasets are mainly produced by well identified member state organisations, usually mandated national cadastral and mapping agencies.
+
+
+
Building data exist with various levels of detail both in geometry and in semantics. For example, there are representations of buildings and constructions as points, surfaces or solids. The 2D surface representation is the most frequent, the building having been captured e.g. by its foot print or roof edge or envelope. The 3D representations of buildings are generally described using the well defined levels of detail of the CityGML OGC standard.
+
+
+
All these various representations have their interest and their limits. For instance, 3D data offer a wonderful tool to design and to communicate about urbanism projects but are far from being accepted by any kind of software. Another example is about the level of detail of the geometric representation: whereas detailed geometry of buildings may be necessary for local use, a more generalised geometry that implies smaller volume of data and so shorter time for computation is generally more suitable for larger areas of interest.
+
+
+
Data model
+
+
+
The data model offers a flexible approach by allowing multiple representations of buildings and constructions, through a set of four profiles with different levels of detail both in geometry and semantics.
+
+
+
The core profiles contain the requirements to be included in the implementing rule. They contain feature types building and building part and a limited set of attributes mainly related to temporal aspects (construction, renovation and demolition dates), physical information (height, number of floors, elevation) and the classification of buildings according to their physical aspect and current use.
+
+
+
+
+
The Buildings2D profile includes various geometrical representations of buildings as 2D or 2,5D data.
+
+
+
The Buildings3D profile has same semantic content as the Buildings2D 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 and installations.
+
+
+
+
+
The BuildingsExtended2D profile is a semantic extension of Buildings2D profile with additional thematic attributes (material of construction, official area or value, connection to utility networks…), classes (building units, installations, other constructions) and references to other data (like cadastral data and addresses).
+
+
+
The BuildingsExtended3D profile is an extension of the Buildings3D profile for rich 3D representations at different levels of details. It includes the possibility to represent many building components, such as the building boundaries (wall, roof …), the openings (doors – windows) and building interior (rooms, internal installations) and the textures associated with the main feature types. 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.
+
+
+
Acknowledgements
+
+
Many individuals and organisations have contributed to the development of these Guidelines.
+
+
+
The Thematic Working Group on Building (TWG-BU) included:
+
+
+
Dominique Laurent (TWG Facilitator), Karl-Gustav Johansson (editor), Simon Barlow, Eddie Bergström, Zsuzsanna Ferencz, Gerhard Gröger, Frank Kooij, Frédéric Mortier, Karen Skjelbo, Fabio Taucer, Amalia Velasco, Ewa Wysocka, Julien Gaffuri (European Commission contact point), Michael Lutz.
+
+
+
Also contributed:
+
+
+
For the final version of the document: Chris Schubert, JRC.
+
+
+
Various persons, among the geographic information community, have been actively involved by supplying information about existing data or about use cases and user requirements. The list of these persons is provided in annex G.
+
+
+
Other contributors to the INSPIRE data specifications are the Drafting Team Data Specifications, the JRC Data Specifications Team and the INSPIRE stakeholders - Spatial Data Interested Communities (SDICs) and Legally Mandated Organisations (LMOs).
This document specifies a harmonised data specification for the spatial data theme Buildings as defined in Annex III of the INSPIRE Directive.
+
+
+
This data specification provides the basis for the drafting of Implementing Rules according to Article 7 (1) of the INSPIRE Directive [Directive 2007/2/EC]. The entire data specification is published as implementation guidelines accompanying these Implementing Rules.
+
+
+
+
+
+
2. Overview
+
+
+
2.1. Name
+
+
INSPIRE data specification for the theme Buildings.
+
+
+
+
2.2. Informal description
+
+
Definition:
+
+
+
Geographical location of buildings [Directive 2007/2/EC].
+
+
+
Description:
+
+
+
Considered as under scope of the theme Buildings are constructions above and/or underground which are intended or used for the shelter of humans, animals, things, the production of economic goods or the delivery of services and that refer to any structure permanently constructed or erected on its site.
+
+
+
2.2.1. Context
+
+
This data specification was developed according to the INSPIRE methodology, the context knowledge being got by an investigation of use cases and user requirements and by a survey of existing data and standards.
+
+
+
2.2.1.1. Use cases
+
+
This data specification about Buildings addresses the following high level use cases shown on the figure below.
+
+
+
In particular, this data specification addresses the Noise Directive, the Air Quality Directive, the Energy Performance of Building Directive and the Population and Housing Census Directive. The Flood Directive and the project of Soil Directive have also been taken into account.
+
+
+
More detailed information about use cases may be found in annex B of this document.
+
+
+
+
+
+
+
+
Figure 1: High level use cases for theme Buildings
+
+
+
+
2.2.1.2. Existing data
+
+
At national level there may be several databases related to the theme Buildings. For instance frequently coexist a topographic view (2D or 2,5D) at scales around 1/ 10 000 and a cadastral view (mostly 2D) at scales generally larger or equal to 1: 2000. In some countries there is also a statistical view on Buildings.
+
+
+
A reliable overview about the databases available at the local level cannot be provided, due to the lack of Reference Material. However, some local governments have volumetric views (3D data) on Buildings.
+
+
+
Moreover there may be other databases dedicated to a specific use case such as marine navigation, air traffic, inventory of buildings with historical or architectural interest. These databases include only a limited set of buildings.
+
+
+
+
2.2.1.3. Existing standards
+
+
This data specification is based on several standards that may be classified as glossaries, classifications and data models:
+
+
+
+
+
Glossaries
+
+
+
+
+
The standard ISO 6707 (Building and Civil Engineering) includes a Vocabulary with part 1 being about General terms.
+
+
+
The standard DFDD (DGIWG Feature Data Dictionary) is the standard established by the military community (DWIWG: Defence Geospatial Information Working Group); it provides terminology and definitions for topographic features, including buildings.
+
+
+
The CLGE (Council of European Geodetic Surveyors) measurement code for the floor area of buildings has provided possible references for the official area of a building.
+
+
+
+
+
Classifications
+
+
+
+
+
Eurostat has a hierarchical classification of types of constructions according to the activity hosted by the building. The part of this classification addressing environmental use cases has been adopted by this data specification; it concerns mainly the residential use.
+
+
+
+
+
Data models
+
+
+
+
+
LADM (Land Administration Domain Model) is the draft standard ISO 19152. It is an extendable basis for efficient cadastral system development based on a Model Driven Architecture. It offers a cadastral view point on Buildings.
+
+
+
CityGML is an OGC standard for the representation of 3D City Models, including Buildings. CityGML offers different levels of detail (LoD) for the mode ling of Buildings:
+
+
+
+
+
LoD 0 that offers a 2D model for buildings has been included in the latest version of City GML (v2.0).
+
+
+
LoD 1 with block models (flat roofs)
+
+
+
LoD 2 with the shape of roofs
+
+
+
LoD 3 with accurate description of exterior (including openings: doors and windows)
+
+
+
LoD 4: interior model
+
+
+
+
+
As this standard is based on ISO TC 211 and OGC concepts, it was a natural candidate for the modeling of 3D Buildings in INSPIRE. Annex D of this document provides more explanations about CityGML and how it has been applied for INSPIRE.
+
+
+
Moreover there are two other standards dealing with very specific use of buildings such as:
+
+
+
+
+
annex 15 of ICAO (International Civil Aviation Organisation) offers a data model for vertical structures (including buildings) called AIXM (Aeronautical Information eXchange Model).
+
+
+
the IHO (International Hydrographic Organisation) has its standard S-57 which comprises the specifications of ENC (Electronic Navigation Charts) and a glossary. Both include information related to theme Buildings.
+
+
+
+
+
+
+
2.2.2. Decisions
+
+
2.2.2.1. The profile approach
+
+
2.2.2.1.1. Semantic aspects
+
+
Various and numerous user requirements were collected. As it seemed impossible to require data harmonisation at European level for all these requirements, this data specification has defined some priority, as shown on the following figure.
+
+
+
+
+
+
+
+
Figure 2: The hierarchy of semantics user requirements (Feature types are represented in bright colours, whereas their properties are represented in clearer colours)
+
+
+
Harmonisation was considered as relevant at European level when funded on international or European use cases and when no significant feasibility issue regarding harmonisation was expected. Harmonisation was considered as relevant at national/local level if funded only on national/local level and/or if feasibility issues were expected (e.g. official data depending on national regulation, privacy issue, lack of consensus about the scope of theme Buildings).
+
+
+
Based on this classification, two kinds of semantic profiles are proposed in this data specification:
+
+
+
+
+
normative core profile based on the data widely used, widely available and whose harmonisation is required at European level, e.g. for homogeneous reporting on Environmental Directives
+
+
+
informative extended profile based on data that is widely required but whose harmonisation is not easily achievable at short term (e.g. data rarely available or data whose harmonisation may/should be done at national level).
+
+
+
+
+
The common semantics used by all profiles has been described in a base application schema.
+
+
+
Core profile includes both basic topographic data (such as height, number of floors, nature of buildings, date of construction …) and coarse official data (such as current use, number of dwellings or of building units); the core profile aims to fulfil most user requirements, at least in a rough way. Core profile is based on the concepts shown in green on the previous figure.
+
+
+
Extended profile includes more detailed information about buildings and building related objects. Extended profile is based on the concepts shown in pink on the previous figure.
+
+
+
Extended profile may be applied as a whole but also aims to be a "reservoir" of proposals for extensions of core INSPIRE profile, i.e. only a selection of proposed feature types and attributes may be added. More explanations about this topic are given in annex F.
+
+
+
Moreover, some mechanisms (external reference, address and document) have been included to enable data producers to provide a link between the data considered as directly under the scope of theme Buildings and business data considered as out of scope of the theme (such as owner/tenant, building permit, detailed activity of the building).
+
+
+
+
2.2.2.1.2. Geometric aspects
+
+
Building data may be available and required either as 2D (or 2,5D) data or as 3D data. This data specification is proposing two kinds of geometric profiles:
+
+
+
+
+
2D profile (with 2D or 2,5D geometry)
+
+
+
3D profile (with 3D geometry)
+
+
+
+
+
NOTE term "2D profile" is used for simplicity reason (in order to have a short title) but accommodates both 2D and 2,5D data.
+
+
+
These 2D and 3D profiles are proposed to make life easier both to data producers and data users:
+
+
+
+
+
most data producers have only 2D or 2,5D data ; it will be easier for them to make their data compliant with core 2D profile that deals only with 2D and 2,5D data
+
+
+
a core 3D profile has been developed, mainly to enable producers of 3D data to conform to INSPIRE model without having to "flatten" their data.
+
+
+
most GIS deals only with 2D or 2,5D data; users will be enabled to choose data compliant with INSPIRE 2D or 3D profiles
+
+
+
+
+
This core normative 3D profile is based on the simple semantic of core profile and allows all the levels of detail of CityGML.
+
+
+
+
2.2.2.1.3. Application schemas and profiles
+
+
The data specification includes six application schemas. Two of them are just abstract application schemas gathering the concepts that are used in common by the other application schemas, i.e. the instanciable ones.
+
+
+
The delivery of data may be done, using four options (called profiles) that consist of a combination of application schemas, as explained in the following table and figure.
+
+
+
Table 1: The profile approach for theme Buildings
+
+
+
+
+
+
+
+
+
+
+
Basic semantic
+
Rich semantic
+
+
+
+
+
2D geometry
+
+
Core 2D profile
+
+
+
uses application schemas:
+
+
+
+
+
base
+
+
+
Buildings2D
+
+
+
+
+
Extended 2D profile
+
+
+
uses application schemas:
+
+
+
- base
+
+
+
- Buildings2D
+
+
+
- base extended
+
+
+
- extended 2D
+
+
+
+
3D geometry
+
+
Core 3D profile
+
+
+
uses application schemas:
+
+
+
+
+
base
+
+
+
Buildings3D
+
+
+
+
+
Extended 3D profile
+
+
+
uses application schemas:
+
+
+
- base
+
+
+
- Buildings3D
+
+
+
- base extended
+
+
+
- extended 3D
+
+
+
+
+
+
The profiles (Core 2D, Core 3D, Extended 2D, Extended 3D) are defined by the respective instanciable application schemas and may use the concepts defined in other application schemas, as explained in the previous table.
+
+
+
+
+
+
+
+
Figure 3: Content and structure of application schemas for theme Buildings
+
+
+
Feature types are represented in blue. Abstract application schemas are represented in green. Instanciable application schemas are represented in red.
+
+
+
NOTE Data producers may also extend INSPIRE profiles by other information not included in this specification, under the condition they respect the rules provided in the Generic Conceptual Model.
+
+
+
+
+
+
+
+
Figure 4: Modular approach for modelling Buildings theme
+
+
+
+
+
2.2.2.2. Modular scope:
+
+
There may be different kinds and sizes of buildings and constructions. In a similar way to the modular levels of information offered by the profile approach, this data specification defines three levels of priority for INSPIRE, regarding the scope of the theme:
+
+
+
+
+
+
+
+
Figure 5: Modular approach for scope of theme Buildings
+
+
+
The first priority, the data the most expected by INSPIRE includes:
+
+
+
+
+
The conventional buildings are considered as building by every one (fitting with all the various definitions of buildings), generally hosting human activities (residential, industrial, commerce and services) and being of large or medium size (around 15-20 m2 and more); these conventional buildings are required by most use cases, such as for assessment of population in an area of interest, census, spatial planning, modelling of physical phenomena. Typical examples are houses, block of flats, factories, supermarkets, …
+
+
+
The specific (significant) buildings are the buildings of significant size or height with specific physical aspect that make them usable as landmarks and required by use cases such as mapping or travel safety. Typical examples are towers, stadium, churches, …
+
+
+
+
+
The second priority, the data that should be in INSPIRE includes:
+
+
+
+
+
The non-conventional buildings fit only partly with the definition(s) of building; for instance, they are only partly constructed, such as caves or underground shelters, stations, car parks or they are permanent only by fact but not by nature such as mobile homes, huts, …If hosting human activities, these non-conventional buildings are required by use cases such as census, studies about precarious habitat, vulnerability to risk
+
+
+
The ancillary buildings are buildings of small size (around 10 m2) that are used only in connection with another larger building, such as the garages or garden shelters near houses. These ancillary buildings may influence the land use / land cover phenomena.
+
+
+
Other constructions are the constructions required by the use cases considered by this data specification. Typical examples are city walls, bridges, chimneys, acoustic fences. The whole list may be found in the model (clause 5).
+
+
+
+
+
The last priority, the data that may be in INSPIRE includes all the other buildings and constructions, mainly the very small size ones (one or several m2), such as phone booth, bus shelters, statues, … These buildings and constructions may be required at local level for asset management, protection of patrimony, …
+
+
+
+
2.2.2.3. Links and overlaps with other themes
+
+
2.2.2.3.1. Overview
+
+
Theme Buildings has overlaps with themes dealing with facilities, as buildings may be part of governmental services, industrial, agricultural, transport or hydrographical facilities and with theme Geographical Names as buildings may have a toponym.
+
+
+
Some buildings and constructions are included in other INSPIRE themes, mainly in the facilities themes (for instance, a building may host a school, a prison, a city hall or be part of a farm or a factory). The general principle is that, for same entities, the theme Building focuses on a physical/topographic view whereas the facility themes focus on a functional view.
+
+
+
Aggregated building data may be found as built-up areas in themes Land Cover or Land Use and as settlements in theme Geographical Names.
+
+
+
Moreover, theme Buildings is often used in conjunction with other INSPIRE themes by the use cases addressed by this data specification. For more details, see annex B.
+
+
+
+
+
+
+
+
Figure 6: Links and overlaps between Buildings and other INSPIRE themes
+
+
+
+
2.2.2.3.2. Classification of buildings
+
+
This data specification proposes a simple classification of buildings, based on their current use. Users will find more detailed information in the themes dealing with facilities.
+
+
+
Table 2: The classification of buildings
+
+
+
+
+
+
+
+
+
Current use – high level
+
Current use – detailed level
+
+
+
+
+
residential
+
Provided by DS BU
+
+
+
agricultural
+
Provided by DS AF
+
+
+
industrial
+
Provided by DS PF
+
+
+
commerceAndServices - office
+
+
+
+
commerceAndServices - trade
+
+
+
+
commerceAndServices – public service
+
Provided by DS US
+
+
+
+
+
+
+
Open issue 1: The articulation between Buildings and facilities was poorly tested or not tested at all during the consultation phase. So, there is a real risk that data between these themes will not connect as expected. This will be a point to be carefully monitored by the maintenance process of INSPIRE specifications.
+
+
+
+
+
+
+
+
+
+
+
Definition:
+
+
+
Geographical location of buildings [Directive 2007/2/EC].
+
+
+
Description:
+
+
+
A building is a covered facility, usable for the protection of humans, animals, things or the production of economic goods. A building refers to any structure permanently constructed or erected on its site. Information on location of buildings may be supplied as points or with the actual basic form of the building. Usually buildings are part of cadastre. On the local level buildings are available within the large scale cadastral maps or cadastral data sets and are geometrically represented as surfaces.
+
+
+
Most buildings can be identified (geocoded) by address (separate theme in INSPIRE).
[Directive 2007/2/EC] Directive 2007/2/EC of the European Parliament and of the Council of 14 March 2007 establishing an Infrastructure for Spatial Information in the European Community (INSPIRE)
+
+
+
[ISO 19107] EN ISO 19107:2005, Geographic Information – Spatial Schema
+
+
+
[ISO 19108] EN ISO 19108:2005, Geographic Information – Temporal Schema
+
+
+
[ISO 19108-c] ISO 19108:2002/Cor 1:2006, Geographic Information – Temporal Schema, Technical Corrigendum 1
+
+
+
[ISO 19111] EN ISO 19111:2007 Geographic information - Spatial referencing by coordinates (ISO 19111:2007)
+
+
+
[ISO 19113] EN ISO 19113:2005, Geographic Information – Quality principles
+
+
+
[ISO 19115] EN ISO 19115:2005, Geographic information – Metadata (ISO 19115:2003)
+
+
+
[ISO 19118] EN ISO 19118:2006, Geographic information – Encoding (ISO 19118:2005)
+
+
+
[ISO 19125-1] EN ISO 19125-1:2004, Geographic Information – Simple feature access – Part 1: Common architecture
+
+
+
[ISO 19135] EN ISO 19135:2007 Geographic information – Procedures for item registration (ISO 19135:2005)
+
+
+
[ISO 19138] ISO/TS 19138:2006, Geographic Information – Data quality measures
+
+
+
[ISO 19139] ISO/TS 19139:2007, Geographic information – Metadata – XML schema implementation
+
+
+
[ISO 19157] ISO/DIS 19157, Geographic information – Data quality
+
+
+
[OGC 06-103r4] Implementation Specification for Geographic Information - Simple feature access – Part 1: Common Architecture v1.2.1
+
+
+
NOTE This is an updated version of "EN ISO 19125-1:2004, Geographic information – Simple feature access – Part 1: Common architecture".
+
+
+
[Regulation 1205/2008/EC] Regulation 1205/2008/EC implementing Directive 2007/2/EC of the European Parliament and of the Council as regards metadata
+
+
+
[Regulation 976/2009/EC] Commission Regulation (EC) No 976/2009 of 19 October 2009 implementing Directive 2007/2/EC of the European Parliament and of the Council as regards the Network Services
+
+
+
[Regulation 1089/2010/EC] Commission Regulation (EU) No 1089/2010 of 23 November 2010 implementing Directive 2007/2/EC of the European Parliament and of the Council as regards interoperability of spatial data sets and services
+
+
+
+
2.4. Terms and definitions
+
+
General terms and definitions helpful for understanding the INSPIRE data specification documents are defined in the INSPIRE Glossary[13].
+
+
+
Specifically, for the theme Buildings, the following terms are defined:
+
+
1. 2D data
+
+
Geometry of features is represented in a two-dimensional space
+
+
+
NOTE In other words, the geometry of 2D data is given using (X,Y) coordinates.
+
+
+
EXAMPLE:
+
+
+
+
+
+
+
+
Figure 7: A building represented by 2D data
+
+
2. 2.5D data
+
+
Geometry of features is represented in a three-dimensional space with the constraint that, for each (X,Y) position, there is only one Z.
+
+
+
EXAMPLE:
+
+
+
+
+
+
+
+
Figure 8: A building represented by 2,5D data
+
+
3. 3D data
+
+
Geometry of features is represented in a three-dimensional space.
+
+
+
NOTE In other words, the geometry of 2D data is given using (X,Y,Z) coordinates without any constraints.
+
+
+
+
+
+
+
+
EXAMPLE:
+
+
+
Figure 9: A building represented by 3D data
+
+
4. Building component
+
+
Any sub-division or elements of a building.
+
+
+
EXAMPLES: wall, roof, room
+
+
+
+
2.5. Symbols and abbreviations
+
+
+
+
+
+
+
+
AC
+
Atmospheric Conditions
+
+
+
AD
+
Address
+
+
+
AF
+
Agricultural and Aquacultural Facilities
+
+
+
ATS
+
Abstract Test Suite
+
+
+
AU
+
Administrative Units
+
+
+
BU
+
Buildings
+
+
+
CP
+
Cadastral Parcels
+
+
+
CRS
+
Coordinate Reference System
+
+
+
DS DT
+
Data Specification Drafting Team
+
+
+
DTM
+
Digital Terrain Model
+
+
+
EC
+
European Commission
+
+
+
EEA
+
European Environmental Agency
+
+
+
EL
+
Elevation
+
+
+
ENC
+
Electronic Navigation Charts
+
+
+
EPBD
+
Energy Performance of Buildings Directive
+
+
+
ETRS89
+
European Terrestrial Reference System 1989
+
+
+
ETRS89-LAEA
+
Lambert Azimuthal Equal Area
+
+
+
EVRS
+
European Vertical Reference System
+
+
+
FE
+
Filter Encoding
+
+
+
GCM
+
General Conceptual Model
+
+
+
GML
+
Geographic Markup Language
+
+
+
GN
+
Geographical Names
+
+
+
GRS80
+
Geodetic Reference System 1980
+
+
+
HY
+
Hydrography
+
+
+
ICAO
+
International Civil Aviation Organization
+
+
+
IR
+
Implementing Rule
+
+
+
ISDSS
+
Interoperability of Spatial Data Sets and Services
+
+
+
ISO
+
International Organization for Standardization
+
+
+
ITRS
+
International Terrestrial Reference System
+
+
+
JRC
+
Joint Research Centre
+
+
+
LADM
+
Land Administration Domain Model
+
+
+
LAT
+
Lowest Astronomical Tide
+
+
+
LC
+
Land Cover
+
+
+
LMO
+
Legally Mandated Organization
+
+
+
LoD
+
Level Of Detail
+
+
+
LU
+
Land Use
+
+
+
MF
+
Meteorological geographical Features
+
+
+
MS
+
Member State
+
+
+
NMCA
+
National Mapping and Cadastral Agency
+
+
+
NZ
+
Natural Risk Zones
+
+
+
OGC
+
Open Geospatial Consortium
+
+
+
OI
+
Orthoimagery
+
+
+
PD
+
Population Distribution
+
+
+
PF
+
Production and Industrial Facilities
+
+
+
RGB
+
Red Green Blue
+
+
+
SDIC
+
Spatial Data Interest Community
+
+
+
SE
+
Style Encoding
+
+
+
SU
+
Statistical Units
+
+
+
TG
+
Technical Guidance
+
+
+
TN
+
Transport Networks
+
+
+
TWG
+
Thematic Working Group
+
+
+
UML
+
Unified Modeling Language
+
+
+
URI
+
Uniform Resource Identifier
+
+
+
US
+
Utility and Governmental Services
+
+
+
UTC
+
Coordinated Universal Time
+
+
+
UTF
+
Unicode Transformation Format
+
+
+
WFS
+
Web Feature Service
+
+
+
WMS
+
Web Map Service
+
+
+
XML
+
EXtensible Markup Language
+
+
+
+
+
+
2.6. How the Technical Guidelines map to the Implementing Rules
+
+
The schematic diagram in Figure 10 gives an overview of the relationships between the INSPIRE legal acts (the INSPIRE Directive and Implementing Rules) and the INSPIRE Technical Guidelines. The INSPIRE Directive and Implementing Rules include legally binding requirements that describe, usually on an abstract level, what Member States must implement.
+
+
+
In contrast, the Technical Guidelines define how Member States might implement the requirements included in the INSPIRE Implementing Rules. As such, they may include non-binding technical requirements that must be satisfied if a Member State data provider chooses to conform to the Technical Guidelines. Implementing these Technical Guidelines will maximise the interoperability of INSPIRE spatial data sets.
+
+
+
+
+
+
+
+
Figure 10 - Relationship between INSPIRE Implementing Rules and Technical Guidelines
+
+
+
2.6.1. Requirements
+
+
The purpose of these Technical Guidelines (Data specifications on Buildings) is to provide practical guidance for implementation that is guided by, and satisfies, the (legally binding) requirements included for the spatial data theme Buildings in the Regulation (Implementing Rules) on interoperability of spatial data sets and services. These requirements are highlighted in this document as follows:
This style is used for requirements contained in the Implementing Rules on interoperability of spatial data sets and services (Commission Regulation (EU) No 1089/2010).
+
+
+
+
+
+
+
For each of these IR requirements, these Technical Guidelines contain additional explanations and examples.
+
+
+
NOTE The Abstract Test Suite (ATS) in Annex A contains conformance tests that directly check conformance with these IR requirements.
+
+
+
Furthermore, these Technical Guidelines may propose a specific technical implementation for satisfying an IR requirement. In such cases, these Technical Guidelines may contain additional technical requirements that need to be met in order to be conformant with the corresponding IR requirement when using this proposed implementation. These technical requirements are highlighted as follows:
+
+
+
+
+
+
📒
+
+
+
+
TG Requirement X
+
+
+
This style is used for requirements for a specific technical solution proposed in these Technical Guidelines for an IR requirement.
+
+
+
+
+
+
+
NOTE 1 Conformance of a data set with the TG requirement(s) included in the ATS implies conformance with the corresponding IR requirement(s).
+
+
+
NOTE 2 In addition to the requirements included in the Implementing Rules on interoperability of spatial data sets and services, the INSPIRE Directive includes further legally binding obligations that put additional requirements on data providers. For example, Art. 10(2) requires that Member States shall, where appropriate, decide by mutual consent on the depiction and position of geographical features whose location spans the frontier between two or more Member States. General guidance for how to meet these obligations is provided in the INSPIRE framework documents.
+
+
+
+
2.6.2. Recommendations
+
+
In addition to IR and TG requirements, these Technical Guidelines may also include a number of recommendations for facilitating implementation or for further and coherent development of an interoperable infrastructure.
+
+
+
+
+
+
📘
+
+
+
+
Recommendation X
+
+
+
Recommendations are shown using this style.
+
+
+
+
+
+
+
NOTE The implementation of recommendations is not mandatory. Compliance with these Technical Guidelines or the legal obligation does not depend on the fulfilment of the recommendations.
+
+
+
+
2.6.3. Conformance
+
+
Annex A includes the abstract test suite for checking conformance with the requirements included in these Technical Guidelines and the corresponding parts of the Implementing Rules (Commission Regulation (EU) No 1089/2010).
+
+
+
+
+
+
+
+
3. Specification scopes
+
+
+
This data specification does not distinguish different specification scopes, but just considers one general scope.
+
+
+
NOTE For more information on specification scopes, see [ISO 19131:2007], clause 8 and Annex D.
+
+
+
+
+
+
4. Identification information
+
+
+
These Technical Guidelines are identified by the following URI:
NOTE ISO 19131 suggests further identification information to be included in this section, e.g. the title, abstract or spatial representation type. The proposed items are already described in the document metadata, executive summary, overview description (section 2) and descriptions of the application schemas (section 5). In order to avoid redundancy, they are not repeated here.
+
+
+
+
+
+
5. Data content and structure
+
+
+
5.1. Application schemas – Overview
+
+
5.1.1. Application schemas included in the IRs
+
+
Articles 3, 4 and 5 of the Implementing Rules lay down the requirements for the content and structure of the data sets related to the INSPIRE Annex themes.
+
+
+
+
+
+
📕
+
+
+
+
IR Requirement
+Article 4
+Types for the Exchange and Classification of Spatial Objects
+
+
+
+
+
For the exchange and classification of spatial objects from data sets meeting the conditions laid down in Article 4 of Directive 2007/2/EC, Member States shall use the spatial object types and associated data types and code lists that are defined in Annexes II, III and IV for the themes the data sets relate to.
+
+
+
When exchanging spatial objects, Member States shall comply with the definitions and constraints set out in the Annexes and provide values for all attributes and association roles set out for the relevant spatial object types and data types in the Annexes. For voidable attributes and association roles for which no value exists, Member States may omit the value.
+
+
+
+
+
+
+
+
+
The types to be used for the exchange and classification of spatial objects from data sets related to the spatial data theme Buildings are defined in the following application schemas (see following sections):
+
+
+
+
+
BuildingsBase application schema describes the concepts that are common to all other Buildings application schemas; it contains mainly the corenormative semantics of theme Buildings
+
+
+
Buildings2D application schema describes the 2D geometric representation of the spatial object types defined in Buildings Base application schema, namely buildings and building parts; it inherits from the common semantics of Buildings base
+
+
+
Buildings3D application schema describes the 3D geometric representation of the spatial object types defined in Buildings Base application schema, namely buildings and building parts; it inherits from the common semantics of Buildings base
+
+
+
+
+
The application schemas specify requirements on the properties of each spatial object including its multiplicity, domain of valid values, constraints, etc.
+
+
+
NOTE The application schemas presented in this section contain some additional information that is not included in the Implementing Rules, in particular multiplicities of attributes and association roles.
+
+
+
+
+
+
📒
+
+
+
+
TG Requirement 1
+
+
+
Spatial object types and data types shall comply with the multiplicities defined for the attributes and association roles in this section.
+
+
+
+
+
+
+
An application schema may include references (e.g. in attributes or inheritance relationships) to common types or types defined in other spatial data themes. These types can be found in a sub-section called "Imported Types" at the end of each application schema section. The common types referred to from application schemas included in the IRs are addressed in Article 3.
+
+
+
+
+
+
📕
+
+
+
+
IR Requirement
+Article 3
+Common Types
+
+
+
Types that are common to several of the themes listed in Annexes I, II and III to Directive 2007/2/EC shall conform to the definitions and constraints and include the attributes and association roles set out in Annex I.
+
+
+
+
+
+
+
NOTE Since the IRs contain the types for all INSPIRE spatial data themes in one document, Article 3 does not explicitly refer to types defined in other spatial data themes, but only to types defined in external data models.
+
+
+
Common types are described in detail in the Generic Conceptual Model [DS-D2.7], in the relevant international standards (e.g. of the ISO 19100 series) or in the documents on the common INSPIRE models [DS-D2.10.x]. For detailed descriptions of types defined in other spatial data themes, see the corresponding Data Specification TG document [DS-D2.8.x].
+
+
+
+
5.1.2. Additional recommended application schemas
+
+
In addition to the application schemas listed above, the following additional application schemas have been defined for the theme Buildings (see following sections):
+
+
+
+
+
BuildingsExtendedBase application schema describes the additional semantics that should be used to extend normative profiles, whatever the chosen geometric representation (2D or 3D) is.
+
+
+
BuildingsExtended2D application schema describes the 2D geometric representation of the additional spatial object types (namely installations, other constructions, building units); it inherits both from the common semantics of <Buildings ExtendedBase> and of the 2D geometric representation of buildings and building parts.
+
+
+
BuildingsExtended3D application schema describes both the 3D geometric representation of the additional spatial object types (namely installations, other constructions, building units) and the additional concepts that should be used to provide more detailed information about buildings and associated objects, when represented by 3D data (walls, roofs, openings, room, textures, …) ; it inherits both from the common semantics of <Buildings ExtendedBase> and of the 3D geometric representation of buildings and building parts.
+
+
+
+
+
These additional application schemas are not included in the IRs. They typically address requirements from specific (groups of) use cases and/or may be used to provide additional information. They are included in this specification in order to improve interoperability also for these additional aspects and to illustrate the extensibility of the application schemas included in the IRs.
+
+
+
+
+
+
+
+
Figure 11: Dependencies between application schemas of theme Buildings
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 1
+
+
+
Additional and/or use case-specific information related to the theme Buildings should be made available using the spatial object types and data types specified in the following application schema(s): BuildingsExtendedBase, BuildingsExtended2D, BuildingsExtended3D.
+
+
+
These spatial object types and data types should comply with the definitions and constraints and include the attributes and association roles defined in this section.
+
+
+
The code lists used in attributes or association roles of spatial object types or data types should comply with the definitions and include the values defined in this section.
+
+
+
+
+
+
+
+
+
5.2. Basic notions
+
+
This section explains some of the basic notions used in the INSPIRE application schemas. These explanations are based on the GCM [DS-D2.5].
+
+
+
5.2.1. Notation
+
+
5.2.1.1. Unified Modeling Language (UML)
+
+
The application schemas included in this section are specified in UML, version 2.1. The spatial object types, their properties and associated types are shown in UML class diagrams.
+
+
+
NOTE For an overview of the UML notation, see Annex D in [ISO 19103].
+
+
+
The use of a common conceptual schema language (i.e. UML) allows for an automated processing of application schemas and the encoding, querying and updating of data based on the application schema – across different themes and different levels of detail.
+
+
+
The following important rules related to class inheritance and abstract classes are included in the IRs.
+
+
+
+
+
+
📕
+
+
+
+
IR Requirement
+Article 5
+Types
+
+
+
(…)
+
+
+
+
+
Types that are a sub-type of another type shall also include all this type’s attributes and association roles.
+
+
+
Abstract types shall not be instantiated.
+
+
+
+
+
+
+
+
+
The use of UML conforms to ISO 19109 8.3 and ISO/TS 19103 with the exception that UML 2.1 instead of ISO/IEC 19501 is being used. The use of UML also conforms to ISO 19136 E.2.1.1.1-E.2.1.1.4.
+
+
+
NOTE ISO/TS 19103 and ISO 19109 specify a profile of UML to be used in conjunction with the ISO 19100 series. This includes in particular a list of stereotypes and basic types to be used in application schemas. ISO 19136 specifies a more restricted UML profile that allows for a direct encoding in XML Schema for data transfer purposes.
+
+
+
To model constraints on the spatial object types and their properties, in particular to express data/data set consistency rules, OCL (Object Constraint Language) is used as described in ISO/TS 19103, whenever possible. In addition, all constraints are described in the feature catalogue in English, too.
+
+
+
NOTE Since "void" is not a concept supported by OCL, OCL constraints cannot include expressions to test whether a value is a void value. Such constraints may only be expressed in natural language.
+
+
+
+
5.2.1.2. Stereotypes
+
+
In the application schemas in this section several stereotypes are used that have been defined as part of a UML profile for use in INSPIRE [DS-D2.5]. These are explained in Table 3 below.
+
+
+
Table 3 – Stereotypes (adapted from [DS-D2.5])
+
+
+
+
+
+
+
+
+
+
Stereotype
+
Model element
+
Description
+
+
+
applicationSchema
+
Package
+
An INSPIRE application schema according to ISO 19109 and the Generic Conceptual Model.
+
+
+
leaf
+
Package
+
A package that is not an application schema and contains no packages.
+
+
+
featureType
+
Class
+
A spatial object type.
+
+
+
type
+
Class
+
A type that is not directly instantiable, but is used as an abstract collection of operation, attribute and relation signatures. This stereotype should usually not be used in INSPIRE application schemas as these are on a different conceptual level than classifiers with this stereotype.
+
+
+
dataType
+
Class
+
A structured data type without identity.
+
+
+
union
+
Class
+
A structured data type without identity where exactly one of the properties of the type is present in any instance.
+
+
+
codeList
+
Class
+
A code list.
+
+
+
import
+
Dependency
+
The model elements of the supplier package are imported.
+
+
+
voidable
+
Attribute, association role
+
A voidable attribute or association role (see section 5.2.2).
+
+
+
lifeCycleInfo
+
Attribute, association role
+
If in an application schema a property is considered to be part of the life-cycle information of a spatial object type, the property shall receive this stereotype.
+
+
+
version
+
Association role
+
If in an application schema an association role ends at a spatial object type, this stereotype denotes that the value of the property is meant to be a specific version of the spatial object, not the spatial object in general.
+
+
+
+
+
+
+
5.2.2. Voidable characteristics
+
+
The «voidable» stereotype is used to characterise those properties of a spatial object that may not be present in some spatial data sets, even though they may be present or applicable in the real world. This does not mean that it is optional to provide a value for those properties.
+
+
+
For all properties defined for a spatial object, a value has to be provided – either the corresponding value (if available in the data set maintained by the data provider) or the value of void. A void value shall imply that no corresponding value is contained in the source spatial data set maintained by the data provider or no corresponding value can be derived from existing values at reasonable costs.
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 2
+
+
+
The reason for a void value should be provided where possible using a listed value from the VoidReasonValue code list to indicate the reason for the missing value.
+
+
+
+
+
+
+
The VoidReasonValue type is a code list, which includes the following pre-defined values:
+
+
+
+
+
Unpopulated: The property is not part of the dataset maintained by the data provider. However, the characteristic may exist in the real world. For example when the "elevation of the water body above the sea level" has not been included in a dataset containing lake spatial objects, then the reason for a void value of this property would be 'Unpopulated'. The property receives this value for all spatial objects in the spatial data set.
+
+
+
Unknown: The correct value for the specific spatial object is not known to, and not computable by the data provider. However, a correct value may exist. For example when the "elevation of the water body above the sea level" of a certain lake has not been measured, then the reason for a void value of this property would be 'Unknown'. This value is applied only to those spatial objects where the property in question is not known.
+
+
+
Withheld: The characteristic may exist, but is confidential and not divulged by the data provider.
+
+
+
+
+
NOTE It is possible that additional reasons will be identified in the future, in particular to support reasons / special values in coverage ranges.
+
+
+
The «voidable» stereotype does not give any information on whether or not a characteristic exists in the real world. This is expressed using the multiplicity:
+
+
+
+
+
If a characteristic may or may not exist in the real world, its minimum cardinality shall be defined as 0. For example, if an Address may or may not have a house number, the multiplicity of the corresponding property shall be 0..1.
+
+
+
If at least one value for a certain characteristic exists in the real world, the minimum cardinality shall be defined as 1. For example, if an Administrative Unit always has at least one name, the multiplicity of the corresponding property shall be 1..*.
+
+
+
+
+
In both cases, the «voidable» stereotype can be applied. In cases where the minimum multiplicity is 0, the absence of a value indicates that it is known that no value exists, whereas a value of void indicates that it is not known whether a value exists or not.
+
+
+
EXAMPLE If an address does not have a house number, the corresponding Address object should not have any value for the «voidable» attribute house number. If the house number is simply not known or not populated in the data set, the Address object should receive a value of void (with the corresponding void reason) for the house number attribute.
+
+
+
+
5.2.3. Code lists
+
+
Code lists are modelled as classes in the application schemas. Their values, however, are managed outside of the application schema.
+
+
+
5.2.3.1. Code list types
+
+
The IRs distinguish the following types of code lists.
+
+
+
+
+
+
📕
+
+
+
+
IR Requirement
+Article 6
+Code Lists for Spatal Data Sets
+
+
+
+
+
The code lists included in this Regulation set out the multilingual thesauri to be used for the key attributes, in accordance with Article 8(2), point (c), of Directive 2007/2/EC.
+
+
+
The Commission shall establish and operate an INSPIRE code list register at Union level for managing and making publicly available the values that are included in the code lists referred to in paragraph 1.
+
+
+
The Commission shall be assisted by the INSPIRE Commission expert group in the maintenance and update of the code list values.
+
+
+
Code lists shall be one of the following types:
+
+
+
+
code lists whose values comprise only the values specified in the INSPIRE code list register;
+
+
+
code lists whose values comprise the values specified in the INSPIRE code list register and narrower values defined by data providers;
+
+
+
code lists whose values comprise the values specified in the INSPIRE code list register and additional values at any level defined by data providers;
+
+
+
code lists, whose values comprise any values defined by data providers.
+
+
+
+
+
+
Code lists may be hierarchical. Values of hierarchical code lists may have a more general parent value.
+
+
+
Where, for an attribute whose type is a code list as referred to in paragraph 4, points (b), (c) or (d), a data provider provides a value that is not specified in the INSPIRE code list register, that value and its definition and label shall be made available in another register.
+
+
+
+
+
+
+
+
+
The type of code list is represented in the UML model through the tagged value extensibility, which can take the following values:
+
+
+
+
+
none, representing code lists whose allowed values comprise only the values specified in the IRs (type a);
+
+
+
narrower, representing code lists whose allowed values comprise the values specified in the IRs and narrower values defined by data providers (type b);
+
+
+
open, representing code lists whose allowed values comprise the values specified in the IRs and additional values at any level defined by data providers (type c); and
+
+
+
any, representing code lists, for which the IRs do not specify any allowed values, i.e. whose allowed values comprise any values defined by data providers (type d).
+
+
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 3
+
+
+
Additional values defined by data providers should not replace or redefine any value already specified in the IRs.
+
+
+
+
+
+
+
NOTE This data specification may specify recommended values for some of the code lists of type (b), (c) and (d) (see section 5.2.4.3). These recommended values are specified in a dedicated Annex.
+
+
+
In addition, code lists can be hierarchical, as explained in Article 6(5) of the IRs.
+
+
+
+
+
+
📕
+
+
+
+
IR Requirement
+Article 6
+Code Lists for Spatial Data Sets
+
+
+
(…)
+
+
+
+
+
Code lists may be hierarchical. Values of hierarchical code lists may have a more generic parent value. Where the valid values of a hierarchical code list are specified in a table in this Regulation, the parent values are listed in the last column.
+
+
+
+
+
+
+
+
+
The type of code list and whether it is hierarchical or not is also indicated in the feature catalogues.
+
+
+
+
5.2.3.2. Obligations on data providers
+
+
+
+
+
📕
+
+
+
+
IR Requirement
+Article 6
+Code Lists for Spatial Datasets
+
+
+
(….)
+
+
+
+
+
Where, for an attribute whose type is a code list as referred to in points (b), (c) or (d) of paragraph 1, a data provider provides a value that is not specified in this Regulation, that value and its definition shall be made available in a register.
+
+
+
+
+
+
+
+
+
Article 6(6) obliges data providers to use only values that are allowed according to the specification of the code list. The "allowed values according to the specification of the code list" are the values explicitly defined in the IRs plus (in the case of code lists of type (b), (c) and (d)) additional values defined by data providers.
+
+
+
For attributes whose type is a code list of type (b), (c) or (d) data providers may use additional values that are not defined in the IRs. Article 6(6) requires that such additional values and their definition be made available in a register. This enables users of the data to look up the meaning of the additional values used in a data set, and also facilitates the re-use of additional values by other data providers (potentially across Member States).
+
+
+
NOTE Guidelines for setting up registers for additional values and how to register additional values in these registers is still an open discussion point between Member States and the Commission.
+
+
+
+
5.2.3.3. Recommended code list values
+
+
For code lists of type (b), (c) and (d), this data specification may propose additional values as a recommendation (in a dedicated Annex). These values will be included in the INSPIRE code list register. This will facilitate and encourage the usage of the recommended values by data providers since the obligation to make additional values defined by data providers available in a register (see section 5.2.4.2) is already met.
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 4
+
+
+
Where these Technical Guidelines recommend values for a code list in addition to those specified in the IRs, these values should be used.
+
+
+
+
+
+
+
NOTE For some code lists of type (d), no values may be specified in these Technical Guidelines. In these cases, any additional value defined by data providers may be used.
+
+
+
+
5.2.3.4. Governance
+
+
The following two types of code lists are distinguished in INSPIRE:
+
+
+
+
+
Code lists that are governed by INSPIRE (INSPIRE-governed code lists). These code lists will be managed centrally in the INSPIRE code list register. Change requests to these code lists (e.g. to add, deprecate or supersede values) are processed and decided upon using the INSPIRE code list register’s maintenance workflows.
+
+
INSPIRE-governed code lists will be made available in the INSPIRE code list register at http://inspire.ec.europa.eu/codelist/<CodeListName>. They will be available in SKOS/RDF, XML and HTML. The maintenance will follow the procedures defined in ISO 19135. This means that the only allowed changes to a code list are the addition, deprecation or supersession of values, i.e. no value will ever be deleted, but only receive different statuses (valid, deprecated, superseded). Identifiers for values of INSPIRE-governed code lists are constructed using the pattern http://inspire.ec.europa.eu/codelist/<CodeListName>/<value>.
+
+
+
+
Code lists that are governed by an organisation outside of INSPIRE (externally governed code lists). These code lists are managed by an organisation outside of INSPIRE, e.g. the World Meteorological Organization (WMO) or the World Health Organization (WHO). Change requests to these code lists follow the maintenance workflows defined by the maintaining organisations. Note that in some cases, no such workflows may be formally defined.
+
+
Since the updates of externally governed code lists is outside the control of INSPIRE, the IRs and these Technical Guidelines reference a specific version for such code lists.
+
+
+
The tables describing externally governed code lists in this section contain the following columns:
+
+
+
+
+
The Governance column describes the external organisation that is responsible for maintaining the code list.
+
+
+
The Source column specifies a citation for the authoritative source for the values of the code list. For code lists, whose values are mandated in the IRs, this citation should include the version of the code list used in INSPIRE. The version can be specified using a version number or the publication date. For code list values recommended in these Technical Guidelines, the citation may refer to the "latest available version".
+
+
+
In some cases, for INSPIRE only a subset of an externally governed code list is relevant. The subset is specified using the Subset column.
+
+
+
The Availability column specifies from where (e.g. URL) the values of the externally governed code list are available, and in which formats. Formats can include machine-readable (e.g. SKOS/RDF, XML) or human-readable (e.g. HTML, PDF) ones.
+
+
+
+
+
Code list values are encoded using http URIs and labels. Rules for generating these URIs and labels are specified in a separate table.
+
+
+
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 5
+
+
+
The http URIs and labels used for encoding code list values should be taken from the INSPIRE code list registry for INSPIRE-governed code lists and generated according to the relevant rules specified for externally governed code lists.
+
+
+
+
+
+
+
NOTE Where practicable, the INSPIRE code list register could also provide http URIs and labels for externally governed code lists.
+
+
+
+
5.2.3.5. Vocabulary
+
+
For each code list, a tagged value called "vocabulary" is specified to define a URI identifying the values of the code list. For INSPIRE-governed code lists and externally governed code lists that do not have a persistent identifier, the URI is constructed following the pattern http://inspire.ec.europa.eu/codelist/<UpperCamelCaseName>;.
+
+
+
If the value is missing or empty, this indicates an empty code list. If no sub-classes are defined for this empty code list, this means that any code list may be used that meets the given definition.
+
+
+
An empty code list may also be used as a super-class for a number of specific code lists whose values may be used to specify the attribute value. If the sub-classes specified in the model represent all valid extensions to the empty code list, the subtyping relationship is qualified with the standard UML constraint "\{complete,disjoint}".
+
+
+
+
+
5.2.4. Identifier management
+
+
+
+
+
📕
+
+
+
+
IR Requirement
+Article 9
+Identifier Management
+
+
+
+
+
The data type Identifier defined in Section 2.1 of Annex I shall be used as a type for the external object identifier of a spatial object.
+
+
+
The external object identifier for the unique identification of spatial objects shall not be changed during the life-cycle of a spatial object.
+
+
+
+
+
+
+
+
+
NOTE 1 An external object identifier is a unique object identifier which is published by the responsible body, which may be used by external applications to reference the spatial object. [DS-D2.5]
+
+
+
NOTE 2 Article 9(1) is implemented in each application schema by including the attribute inspireId of type Identifier.
+
+
+
NOTE 3 Article 9(2) is ensured if the namespace and localId attributes of the Identifier remains the same for different versions of a spatial object; the version attribute can of course change.
+
+
+
+
5.2.5. Geometry representation
+
+
+
+
+
📕
+
+
+
+
IR Requirement
+Article 12
+Other Requirements & Rules
+
+
+
+
+
The value domain of spatial properties defined in this Regulation shall be restricted to the Simple Feature spatial schema as defined in Herring, John R. (ed.), OpenGIS® Implementation Standard for Geographic information – Simple feature access – Part 1: Common architecture, version 1.2.1, Open Geospatial Consortium, 2011, unless specified otherwise for a specific spatial data theme or type.
+
+
+
+
+
+
+
+
+
NOTE 1 The specification restricts the spatial schema to 0-, 1-, 2-, and 2.5-dimensional geometries where all curve interpolations are linear and surface interpolations are performed by triangles.
+
+
+
NOTE 2 The topological relations of two spatial objects based on their specific geometry and topology properties can in principle be investigated by invoking the operations of the types defined in ISO 19107 (or the methods specified in EN ISO 19125-1).
+
+
+
+
5.2.6. Temporality representation
+
+
The application schema(s) use(s) the derived attributes "beginLifespanVersion" and "endLifespanVersion" to record the lifespan of a spatial object.
+
+
+
The attributes "beginLifespanVersion" specifies the date and time at which this version of the spatial object was inserted or changed in the spatial data set. The attribute "endLifespanVersion" specifies the date and time at which this version of the spatial object was superseded or retired in the spatial data set.
+
+
+
NOTE 1 The attributes specify the beginning of the lifespan of the version in the spatial data set itself, which is different from the temporal characteristics of the real-world phenomenon described by the spatial object. This lifespan information, if available, supports mainly two requirements: First, knowledge about the spatial data set content at a specific time; second, knowledge about changes to a data set in a specific time frame. The lifespan information should be as detailed as in the data set (i.e., if the lifespan information in the data set includes seconds, the seconds should be represented in data published in INSPIRE) and include time zone information.
+
+
+
NOTE 2 Changes to the attribute "endLifespanVersion" does not trigger a change in the attribute "beginLifespanVersion".
+
+
+
+
+
+
📕
+
+
+
+
IR Requirement
+Article 10
+Life-cycle of Spatial Objects
+
+
+
(…)
+
+
+
+
+
Where the attributes beginLifespanVersion and endLifespanVersion are used, the value of endLifespanVersion shall not be before the value of beginLifespanVersion.
+
+
+
+
+
+
+
+
+
NOTE The requirement expressed in the IR Requirement above will be included as constraints in the UML data models of all themes.
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 6
+
+
+
If life-cycle information is not maintained as part of the spatial data set, all spatial objects belonging to this data set should provide a void value with a reason of "unpopulated".
+
+
+
+
+
+
+
+
+
5.3. Application schema BuildingsBase
+
+
5.3.1. Description
+
+
5.3.1.1. Narrative description
+
+
Buildings Base application schema is an abstract application schema that describes the feature types, data types and code lists that are common to all the four instanciable application schemas, namely 2D, 3D, extended2D and extended3D.
+
+
+
It addresses mainly the basic normative semantics and includes in addition a data type about the 2D geometric representation of buildings that is used by all the four instanciable application schemas.
+
+
+
5.3.1.1.1. Feature types
+
+
+
+
+
+
+
Figure 12: Instanciable feature types
+
+
+
Buildings are enclosed constructions above and/or underground which are intended or used for the shelter of humans, animals, things or the production of economic goods and that refer to any structure permanently constructed or erected on its site.
+
+
+
According to a CityGML concept, a complex building may be considered as an aggregation of BuildingParts, as shown on the following illustration:
+
+
+
+
+
+
+
+
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.
+
+
+
+
+
+
+
+
Figure 13: Feature types of Buildings Base application schema
+
+
+
Base application schema includes 2 abstract feature types: AbstractConstruction and AbstractBuilding:
+
+
+
+
+
AbstractBuilding is an abstract feature type grouping the common properties of instanciable feature types Building and BuildingPart
+
+
+
AbstractConstruction is an abstract feature type grouping the semantic properties of buildings, building parts and of some optional feature types that may be added to core profiles, in order to provide more information about theme Buildings. The optional feature types are described in extended application schemas.
+
+
+
+
+
Instanciable feature types Building and BuildingPart inherit both of the properties of abstract feature types AbstractConstruction and AbstractBuilding.
+
+
+
+
5.3.1.1.2. Elevation
+
+
+
+
+
+
+
+
+
+
+
+
Figure 14: The Elevation data type
+
+
+
A building or a construction may have several values of attribute elevation:
+
+
+
+
+
the elevation may be measured at different levels of the building; this must be documented with attribute elevationReference, using the possible values given in the code list ElevationReferenceValue (see Figure 15: Examples of elevation references for different kinds of building)
+
+
+
the elevation may be given in various vertical reference systems; this has to be documented through the DirectPosition that contains both the elevation value itself and the Coordinate Reference System to which this value refers.
+
+
+
+
+
EXAMPLE (DirectPosition):
+<pos srsName="urn:x-ogc:def:crs:EPSG:7.9.5. 5621" srsDimension="1">114</pos>
+The Spatial Reference System Name (srsName) is given by:
+
+
+
+
+
EPSG :7.9.5 : namespace (or register) and its version
+
+
+
5621 : identifier of the CRS in the given register (here it is EVRF 2007)
+
+
+
+
+
The srsDimension is 1 because related only to one dimension (elevation).
+
+
+
The value of elevation is 114.
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 7
+
+
+
For territories that are in the scope of EVRS, the use EVRS as elevation datum is recommended.
+
+
+
+
+
+
+
However, some communities as marine or air navigation may have other requirements, coming from international standards.
+
+
+
+
+
+
+
+
Figure 15: Examples of elevation references for different kinds of building
+
+
+
+
5.3.1.1.3. Attribute HeightAboveGround
+
+
A construction of a building may have several values for the attribute HeightAboveGround, according to the levels that were chosen to compute it. The heightAboveGround of a construction or building is generally computed as the difference between an elevation measured at a high reference and the elevation measured at a low reference.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Figure 16: The HeightAboveGround data type
+
+
+
It is recommended to use:
+
+
+
+
+
For the low reference
+
+
+
+
generalGround
+
+
+
lowestGroundPoint
+
+
+
lowestFloorAboveGround
+
+
+
entrancePoint
+
+
+
highestGroundPoint
+
+
+
+
+
+
For the high reference
+
+
+
+
generalRoofEdge
+
+
+
lowestRoofEdge
+
+
+
highestRoofEdge
+
+
+
generalEave
+
+
+
lowestEave
+
+
+
highestEave
+
+
+
generalRoof
+
+
+
top OfConstruction
+
+
+
highestPoint
+
+
+
+
+
+
+
+
+
5.3.1.1.4. Classification of buildings
+
+
The classification of buildings has to be done using two attributes:
+
+
+
+
+
the attribute currentUse that focuses on the activity hosted by the building; this attribute aims to fulfil management requirements, such as computation of population or spatial planning ; this classification aims to be exhaustive for the functional buildings hosting human activities
+
+
+
the attribute buildingNature that focuses on the physical aspect of the building; however, this physical aspect is often expressed as a function (e.g. stadium, silo, windmill); this attribute aims to fulfil mainly mapping purposes and addresses only specific, noticeable buildings. This is a rather short and simple list of possible values, with focus on two international use cases: air flights where buildings may be obstacles and marine navigation where buildings may be landmarks.
+
+
+
+
+
The code list for attribute buildingNature may be extended by Member States, in order to fulfil more mapping requirements.
+
+
+
The attribute currentUse may take its possible values in a hierarchical code list. This hierarchical code list should enable easy matching from existing classifications to the INSPIRE classification:
+
+
+
+
+
a data producer with simple classification may match at the upper level of INSPIRE classification (e.g. residential / agriculture / industrial / commerceAndService)
+
+
+
a data producer with a more detailed classification may match at the lower levels of INSPIRE classification (e.g. moreThanTwoDwellings, publicServices, …).
+
+
+
+
+
The code list for attribute currentUse may also be extended by Member States, but only by providing more detailed values, under the hierarchical structure of the INSPIRE code list.
+
+
+
Some examples are provided in the annex F.
+
+
+
+
+
+
+
+
Figure 17: 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 18: Building nature
+
+
+
+
5.3.1.1.5. Attribute externalReference
+
+
+
+
+
+
+
Figure 19: The attribute externalReference is defined as a data type
+
+
+
This attribute aims to ensure the link to other information systems, for instance:
+
+
+
+
+
another spatial data set including building data; in this case, the external reference contributes to ensure consistency between different views or different levels of detail on same real-world objects, that is an explicit requirement of the INSPIRE Directive,
+
+
+
the cadastral register where information about owner, tenant, criteria of valuation (heating, toilet, …) may be found.
+
+
+
+
+
+
5.3.1.1.6. Geometry of buildings
+
+
All instanciable application schema include an attribute geometry2D, with multiplicity [1..*]. This attribute is mandatory in 2D profiles and voidable in 3D profiles. The Buildings base application schema does not contain the attribute geometry2D itself but it describes the data type used to represent it: BuildingGeometry2D.
+
+
+
The INSPIRE model is quite flexible as it allows the geometry of a building to be represented in different ways. Multiple geometries are allowed for buildings; for instance, a data producer may provide representation of a building as a surface and as a point or as several surfaces, e.g. the building captured by its foot print and by its roof edges.
+
+
+
Whereas the representation by surfaces is expected by most use cases, the representation by point is useful to make some computations quicker (e.g. computation of distances).
+
+
+
However, a view service may only use one geometry; the geometry to be chosen by the view service is documented through the Boolean attribute referenceGeometry: there shall be only one geometric representation whose attribute referenceGeometry gets the value "true". In case of representation by point and by surface, the surface should generally be the reference geometry.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Figure 20: The geometry of Building and BuildingPart has to be documented
+
+
+
A building is a 3D object represented in this profile by 2D or 2,5 D data:
+
+
+
+
+
the place where (X,Y) coordinates were captured has to be documented using the attribute horizontalGeometryReference;
+
+
+
the place where Z coordinate was captured must be documented using the attribute verticalGeometryReference.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Figure 21: Examples of HorizontalGeometryReference
+
+
+
NOTE The possible values of attribute horizontalGeometryReference depend on the geometric representation of the building or building part, as shown in the Table 4 below.
+
+
+
Table 4: Correspondence between geometry and horizontalGeometryReference
+
+
+
+
+
+
+
+
+
+
geometry
+
GM_Point
+
GM_Surface
+
+GM_MultiSurface
+
+
+
+
+
horizontalGeometryReference
+
+
entrancePoint
+
+
+
pointInsideBuilding
+
+
+
pointInsideCadastralParcel
+
+
+
Footprint
+
+
+
Roofedge
+
+
+
aboveGroundEnvelope
+
+
+
envelope
+
+
+
lowestFloorAboveGround
+
+
+
combined
+
+
+
+
+
+
NOTE it is not forbidden to represent different levels of detail of the same building. The model allows for instance to represent the geometries of the building, captured at different scales, using the same horizontal geometry reference., e.g. a building captured by its roof edge with different generalisation rules or from aerial images taken at different original scales. In this case, it is strongly recommended to provide the attribute horizontalGeometryEstimatedAccuracy and/or to give referenceGeometry to the most detailed one.
+
+
+
+
+
5.3.1.2. UML Overview
+
+
+
+
+
+
+
Figure 22: UML class diagram: Overview of the Building Base - Main types
+
+
+
+
+
+
+
+
Figure 23: UML class diagram: Overview of the Building Base - Data types
+
+
+
+
+
+
+
+
Figure 24: UML class diagram: Overview of the Building Base - Code lists
+
+
+
+
5.3.1.3. Consistency between spatial data sets
+
+
There should be some consistency between the value of attribute currentUse in theme Buildings and the location of agricultural facilities, industrial or production facilities and governmental services. Typically:
+
+
+
+
+
Buildings within an agricultural or aquacultural facility should generally have value "agricultural" for attribute current use
+
+
+
Buildings within an industrial or production facility should generally have value "industrial" for attribute current use
+
+
+
Buildings within a governmental service should generally have value "public services" for attribute current use
+
+
+
+
+
However, there may be exceptions (e.g. a residential building for guardian in a production site or for teacher in a school or for farmer in an agricultural facility); moreover, the geometry of facilities or governmental services may be represented in some cases just by a point and so, may not always enable to identified the related buildings. Consequently, no absolute consistency rule can be provided.
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 8
+
+
+
Member States and/or National Spatial Data Infrastructures should encourage cooperation between data providers of themes Buildings and of themes Agricultural and Aquacultural Facilities, Production and Industrial facilities and Utility and Governmental Services in order to provide consistent data.
+
+
+
+
+
+
+
+
5.3.1.4. Identifier management
+
+
The buildings and building parts have to be identified by the mandatory attribute inspireID; this unique identification enables the buildings and building parts to be target of associations from other INSPIRE themes, e.g. from theme Address.
+
+
+
+
5.3.1.5. Modelling of object references
+
+
The base application schema offers one option to link a spatial object (building or building part) defined in INSPIRE to information in other systems: the attribute externalReference provides the identifier/reference of the object in that foreign system together with the name and the URI of that information system. This external reference for instance may be used to obtain information about the owner of the building from a cadastral system.
+
+
+
The external information systems that may/should be linked to theme Buildings depend of course of national context and regulations.
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 9
+
+
+
Member States and/or National Spatial Data Infrastructures should agree on the external information systems to be linked to theme Buildings.
+
+
+
+
+
+
+
+
+
5.3.2. Feature catalogue
+
+
Feature catalogue metadata
+
+
+
+
+
+
+
+
+
Application Schema
+
INSPIRE Application Schema BuildingsBase
+
+
+
Version number
+
3.0
+
+
+
+
+
Types defined in the feature catalogue
+
+
+
+
+
+
+
+
+
+
Type
+
Package
+
Stereotypes
+
+
+
+
+
AbstractBuilding
+
BuildingsBase
+
«featureType»
+
+
+
AbstractConstruction
+
BuildingsBase
+
«featureType»
+
+
+
Building
+
BuildingsBase
+
«featureType»
+
+
+
BuildingGeometry2D
+
BuildingsBase
+
«dataType»
+
+
+
BuildingNatureValue
+
BuildingsBase
+
«codeList»
+
+
+
BuildingPart
+
BuildingsBase
+
«featureType»
+
+
+
ConditionOfConstructionValue
+
BuildingsBase
+
«codeList»
+
+
+
CurrentUse
+
BuildingsBase
+
«dataType»
+
+
+
CurrentUseValue
+
BuildingsBase
+
«codeList»
+
+
+
DateOfEvent
+
BuildingsBase
+
«dataType»
+
+
+
Elevation
+
BuildingsBase
+
«dataType»
+
+
+
ElevationReferenceValue
+
BuildingsBase
+
«codeList»
+
+
+
ExternalReference
+
BuildingsBase
+
«dataType»
+
+
+
HeightAboveGround
+
BuildingsBase
+
«dataType»
+
+
+
HeightStatusValue
+
BuildingsBase
+
«codeList»
+
+
+
HorizontalGeometryReferenceValue
+
BuildingsBase
+
«codeList»
+
+
+
+
+
5.3.2.1. Spatial object types
+
+
5.3.2.1.1. AbstractConstruction
+
+
+
+
+
+
+
AbstractConstruction (abstract)
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
Abstract construction
+
+
+
Definition:
+
Abstract spatial object type grouping the semantic properties of buildings, building parts and of some optional spatial object types that may be added in order to provide more information about the theme Buildings.
+
+
+
Description:
+
The optional spatial object types that may be added to core profiles are described in the extended profiles. The ones inheriting from the attributes of AbstractConstruction are Installation and OtherConstruction.
+
+
+
Stereotypes:
+
«featureType»
+
+
+
+
+
+
+
Attribute: beginLifespanVersion
+
+
+
+
+
+
+
+
+
Name:
+
Begin lifespan version
+
+
+
Value type:
+
DateTime
+
+
+
Definition:
+
Date and time at which this version of the spatial object was inserted or changed in the spatial data set.
+
+
+
Multiplicity:
+
1
+
+
+
Stereotypes:
+
«voidable,lifeCycleInfo»
+
+
+
+
+
+
+
Attribute: conditionOfConstruction
+
+
+
+
+
+
+
+
+
Name:
+
Condition of construction
+
+
+
Value type:
+
ConditionOfConstructionValue
+
+
+
Definition:
+
Status of the construction.
+
+
+
Description:
+
EXAMPLES: functional, projected, ruin
+
+
+
Multiplicity:
+
1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: dateOfConstruction
+
+
+
+
+
+
+
+
+
Name:
+
Date of construction
+
+
+
Value type:
+
DateOfEvent
+
+
+
Definition:
+
Date of construction.
+
+
+
Multiplicity:
+
0..1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: dateOfDemolition
+
+
+
+
+
+
+
+
+
Name:
+
Date of demolition
+
+
+
Value type:
+
DateOfEvent
+
+
+
Definition:
+
Date of demolition.
+
+
+
Multiplicity:
+
0..1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: dateOfRenovation
+
+
+
+
+
+
+
+
+
Name:
+
Date of last major renovation
+
+
+
Value type:
+
DateOfEvent
+
+
+
Definition:
+
Date of last major renovation.
+
+
+
Multiplicity:
+
0..1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: elevation
+
+
+
+
+
+
+
+
+
Name:
+
Elevation
+
+
+
Value type:
+
Elevation
+
+
+
Definition:
+
Vertically-constrained dimensional property consisting of an absolute measure referenced to a well-defined surface which is commonly taken as origin (geoïd, water level, etc.).
+
+
+
Description:
+
Source: adapted from the definition given in the data specification of the theme Elevation.
+
+
+
Multiplicity:
+
0..*
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: endLifespanVersion
+
+
+
+
+
+
+
+
+
Name:
+
End lifespan version
+
+
+
Value type:
+
DateTime
+
+
+
Definition:
+
Date and time at which this version of the spatial object was superseded or retired in the spatial data set.
+
+
+
Multiplicity:
+
0..1
+
+
+
Stereotypes:
+
«voidable,lifeCycleInfo»
+
+
+
+
+
+
+
Attribute: externalReference
+
+
+
+
+
+
+
+
+
Name:
+
External reference
+
+
+
Value type:
+
ExternalReference
+
+
+
Definition:
+
Reference to an external information system containing any piece of information related to the spatial object.
+
+
+
Description:
+
EXAMPLE 1: Reference to another spatial data set containing another view on buildings; the externalReference may be used for instance to ensure consistency between 2D and 3D representations of the same buildings
+
+EXAMPLE 2: Reference to cadastral or dwelling register. The reference to this register may enable to find legal information related to the building, such as the owner(s) or valuation criteria (e.g. type of heating, toilet, kitchen)
+
+EXAMPLE 3: Reference to the system recording the building permits. The reference to the building permits may be used to find detailed information about the building physical and temporal aspects.
+
+
+
Multiplicity:
+
0..*
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: heightAboveGround
+
+
+
+
+
+
+
+
+
Name:
+
Height above ground
+
+
+
Value type:
+
HeightAboveGround
+
+
+
Definition:
+
Height above ground.
+
+
+
Description:
+
NOTE height above ground may be defined as the difference between elevation at a low reference (ground level) and elevation as a high reference (e.g. roof level, top of construction)
+
+
+
Multiplicity:
+
0..*
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: inspireId
+
+
+
+
+
+
+
+
+
Name:
+
inspire id
+
+
+
Value type:
+
Identifier
+
+
+
Definition:
+
External object identifier of the spatial object.
+
+
+
Description:
+
An external object identifier is a unique object identifier published by the responsible body, which may be used by external applications to reference the spatial object. The identifier is an identifier of the spatial object, not an identifier of the real-world phenomenon.
+
+
+
Multiplicity:
+
1
+
+
+
+
+
+
+
Attribute: name
+
+
+
+
+
+
+
+
+
Value type:
+
GeographicalName
+
+
+
Definition:
+
Name of the construction.
+
+
+
Description:
+
EXAMPLES: Big Ben, Eiffel Tower, Sacrada Familia
+
+
+
Multiplicity:
+
0..*
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
+
+
5.3.2.1.2. AbstractBuilding
+
+
+
+
+
+
+
AbstractBuilding (abstract)
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
Abstract building
+
+
+
Subtype of:
+
AbstractConstruction
+
+
+
Definition:
+
Abstract spatial object type grouping the common semantic properties of the spatial object types Building and BuildingPart.
+
+
+
Stereotypes:
+
«featureType»
+
+
+
+
+
+
+
Attribute: buildingNature
+
+
+
+
+
+
+
+
+
Name:
+
Building nature
+
+
+
Value type:
+
BuildingNatureValue
+
+
+
Definition:
+
Characteristic of the building that makes it generally of interest for mappings applications. The characteristic may be related to the physical aspect and/or to the function of the building.
+
+
+
Description:
+
This attribute focuses on the physical aspect of the building; however, this physical aspect is often expressed as a function (e.g. stadium, silo, windmill); this attribute aims to fulfil mainly mapping purposes and addresses only specific, noticeable buildings.
+
+
+
Multiplicity:
+
0..*
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: currentUse
+
+
+
+
+
+
+
+
+
Name:
+
Current use
+
+
+
Value type:
+
CurrentUse
+
+
+
Definition:
+
Activity hosted within the building. This attribute addresses mainly the buildings hosting human activities.
+
+
+
Description:
+
NOTE . This attribute aims to fulfill management requirements, such as computation of population or spatial planning ; this classification aims to be exhaustive for the functional buildings hosting human activities.
+
+
+
Multiplicity:
+
0..*
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: numberOfDwellings
+
+
+
+
+
+
+
+
+
Name:
+
Number of dwellings
+
+
+
Value type:
+
Integer
+
+
+
Definition:
+
Number of dwellings.
+
+
+
Description:
+
A dwelling is a residential unit which may consist of one or several rooms designed for the occupation of households.
+NOTE In the data sets including building units, a dwelling is a residential building unit or, only when that building has no building units, a residential building.
+EXAMPLES: a single building dwelling could be a detached or semi-detached house. A block of flats will contain multiple dwellings determined by the number of individual flats.
+
+
+
Multiplicity:
+
0..1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: numberOfBuildingUnits
+
+
+
+
+
+
+
+
+
Name:
+
Number of building units
+
+
+
Value type:
+
Integer
+
+
+
Definition:
+
Number of building units in the building. A BuildingUnit is a subdivision of Building with its own lockable access from the outside or from a common area (i.e. not from another BuildingUnit), which is atomic, functionally independent, and may be separately sold, rented out, inherited, etc.
+
+
+
Description:
+
Building units are spatial objects aimed at subdividing buildings and/or building parts into smaller parts that are treated as seperate entities in daily life. A building unit is homogeneous, regarding management aspects.
+EXAMPLES: It may be e.g. an apartment in a condominium, a terraced house, or a shop inside a shopping arcade.
+NOTE 1: According to national regulations, a building unit may be a flat, a cellar, a garage or set of a flat, a cellar and a garage.
+NOTE 2: According to national regulation, a building that is one entity for daily life (typically, a single family house) may be considered as a Building composed of one BuildingUnit or as a Building composed of zero BuildingUnit.
+
+
+
Multiplicity:
+
0..1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: numberOfFloorsAboveGround
+
+
+
+
+
+
+
+
+
Name:
+
Number of floors above ground
+
+
+
Value type:
+
Integer
+
+
+
Definition:
+
Number of floors above ground.
+
+
+
Multiplicity:
+
0..1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
+
+
5.3.2.1.3. Building
+
+
+
+
+
+
+
Building (abstract)
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
Building
+
+
+
Subtype of:
+
AbstractBuilding
+
+
+
Definition:
+
A Building is an enclosed construction above and/or underground, used or intended for the shelter of humans, animals or things or for the production of economic goods. A building refers to any structure permanently constructed or erected on its site.
+
+
+
Stereotypes:
+
«featureType»
+
+
+
+
+
+
+
Association role: parts
+
+
+
+
+
+
+
+
+
Value type:
+
BuildingPart
+
+
+
Definition:
+
The building parts composing the Building.
+
+
+
Description:
+
A building may be a simple building (with no BuildingPart) or a composed building (with several BuildingParts).
+
+
+
Multiplicity:
+
0..*
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
+
+
5.3.2.1.4. BuildingPart
+
+
+
+
+
+
+
BuildingPart (abstract)
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
Building part
+
+
+
Subtype of:
+
AbstractBuilding
+
+
+
Definition:
+
A BuildingPart is a sub-division of a Building that might be considered itself as a building.
+
+
+
Description:
+
NOTE 1: A BuildingPart is homogeneous related to its physical, functional or temporal aspects.
+
+NOTE 2: Building and BuildingPart share the same set of properties.
+EXAMPLE: A building may be composed of two building parts having different heights above ground.
+
+
+
Stereotypes:
+
«featureType»
+
+
+
+
+
+
+
+
+
+
5.3.2.2. Data types
+
+
5.3.2.2.1. DateOfEvent
+
+
+
+
+
+
+
DateOfEvent
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
Date of event
+
+
+
Definition:
+
This data type includes the different possible ways to define the date of an event.
+
+
+
Stereotypes:
+
«dataType»
+
+
+
+
+
+
+
Attribute: anyPoint
+
+
+
+
+
+
+
+
+
Name:
+
Any point
+
+
+
Value type:
+
DateTime
+
+
+
Definition:
+
A date and time of any point of the event, between its beginning and its end.
+
+
+
Multiplicity:
+
0..1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: beginning
+
+
+
+
+
+
+
+
+
Name:
+
Beginning
+
+
+
Value type:
+
DateTime
+
+
+
Definition:
+
Date and time when the event begun.
+
+
+
Multiplicity:
+
0..1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: end
+
+
+
+
+
+
+
+
+
Name:
+
End
+
+
+
Value type:
+
DateTime
+
+
+
Definition:
+
Date and time when the event ended.
+
+
+
Multiplicity:
+
0..1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Constraint: atLeastOneEvent
+
+
+
+
+
+
+
+
+
Natural language:
+
At least, one of the attributes beginning, end or anyPoint shall be supplied.
+
+
+
OCL:
+
inv: dateOfEvent→notEmpty()
+
+
+
+
+
+
+
Constraint: beginning is before anyPoint is before end
+
+
+
+
+
+
+
+
+
Natural language:
+
+
+
+
OCL:
+
inv: beginning ⇐ anyPoint and anyPoint ⇐ end and beginning ⇐ end
+
+
+
+
+
+
+
+
+
5.3.2.2.2. HeightAboveGround
+
+
+
+
+
+
+
HeightAboveGround
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
Height above ground
+
+
+
Definition:
+
Vertical distance (measured or estimated) between a low reference and a high reference.
+
+
+
Stereotypes:
+
«dataType»
+
+
+
+
+
+
+
Attribute: heightReference
+
+
+
+
+
+
+
+
+
Name:
+
Height reference
+
+
+
Value type:
+
ElevationReferenceValue
+
+
+
Definition:
+
Element used as the high reference.
+
+
+
Description:
+
EXAMPLE: The height of the building has been captured up to the top of building.
+
+
+
Multiplicity:
+
1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: lowReference
+
+
+
+
+
+
+
+
+
Name:
+
Low reference
+
+
+
Value type:
+
ElevationReferenceValue
+
+
+
Definition:
+
Element as the low reference.
+
+
+
Description:
+
EXAMPLE: the height of the building has been captured from its the lowest ground point.
+
+
+
Multiplicity:
+
1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: status
+
+
+
+
+
+
+
+
+
Name:
+
Status
+
+
+
Value type:
+
HeightStatusValue
+
+
+
Definition:
+
The way the height has been captured.
+
+
+
Multiplicity:
+
1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: value
+
+
+
+
+
+
+
+
+
Name:
+
Value
+
+
+
Value type:
+
Length
+
+
+
Definition:
+
Value of the height above ground.
+
+
+
Multiplicity:
+
1
+
+
+
+
+
+
+
Constraint: valueUoMIsMetre
+
+
+
+
+
+
+
+
+
Natural language:
+
Value shall be in meters.
+
+
+
OCL:
+
inv: self.value.uom.uomSymbol='m'
+
+
+
+
+
+
+
+
+
5.3.2.2.3. Elevation
+
+
+
+
+
+
+
Elevation
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
Elevation
+
+
+
Definition:
+
This data types includes the elevation value itself and information on how this elevation was measured.
+
+
+
Stereotypes:
+
«dataType»
+
+
+
+
+
+
+
Attribute: elevationReference
+
+
+
+
+
+
+
+
+
Name:
+
Elevation reference
+
+
+
Value type:
+
ElevationReferenceValue
+
+
+
Definition:
+
Element where the elevation was measured.
+
+
+
Multiplicity:
+
1
+
+
+
+
+
+
+
Attribute: elevationValue
+
+
+
+
+
+
+
+
+
Name:
+
elevation value
+
+
+
Value type:
+
DirectPosition
+
+
+
Definition:
+
Value of the elevation.
+
+
+
Multiplicity:
+
1
+
+
+
+
+
+
+
+
+
5.3.2.2.4. BuildingGeometry2D
+
+
+
+
+
+
+
BuildingGeometry2D
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
Building geometry 2D
+
+
+
Definition:
+
This data types includes the geometry of the building and metadata information about which element of the building was captured and how.
+
+
+
Stereotypes:
+
«dataType»
+
+
+
+
+
+
+
Attribute: geometry
+
+
+
+
+
+
+
+
+
Name:
+
Geometry
+
+
+
Value type:
+
GM_Object
+
+
+
Definition:
+
2D or 2.5D geometric representation
+
+
+
Multiplicity:
+
1
+
+
+
+
+
+
+
Attribute: referenceGeometry
+
+
+
+
+
+
+
+
+
Name:
+
Reference geometry
+
+
+
Value type:
+
Boolean
+
+
+
Definition:
+
The geometry to be taken into account by view services, for portrayal.
+
+
+
Description:
+
NOTE 1: In case of multiple representation by point and by surface, it is generally recommended to provide the surface as reference geometry.
+NOTE 2: The geometric representation whose referenceGeometry is true may also be used preferably for spatial queries by download services (WFS) or by Geographical Information System (GIS).
+
+
+
Multiplicity:
+
1
+
+
+
+
+
+
+
Attribute: horizontalGeometryReference
+
+
+
+
+
+
+
+
+
Name:
+
Horizontal geometry reference
+
+
+
Value type:
+
HorizontalGeometryReferenceValue
+
+
+
Definition:
+
Element of the building that was captured by (X,Y) coordinates.
+
+
+
Multiplicity:
+
1
+
+
+
+
+
+
+
Attribute: verticalGeometryReference
+
+
+
+
+
+
+
+
+
Name:
+
Vertical geometry reference
+
+
+
Value type:
+
ElevationReferenceValue
+
+
+
Definition:
+
Element of the building that was captured by vertical coordinates.
+
+
+
Multiplicity:
+
0..1
+
+
+
+
+
+
+
Attribute: horizontalGeometryEstimatedAccuracy
+
+
+
+
+
+
+
+
+
Name:
+
Horizontal geometry estimated accuracy
+
+
+
Value type:
+
Length
+
+
+
Definition:
+
The estimated absolute positional accuracy of the (X,Y) coordinates of the building geometry, in the INSPIRE official Coordinate Reference System. Absolute positional accuracy is defined as the mean value of the positional uncertainties for a set of positions where the positional uncertainties are defined as the distance between a measured position and what is considered as the corresponding true position.
+
+
+
Description:
+
NOTE This mean value may come from quality measures on a homogeneous population of buildings or from an estimation based on the knowledge of the production processes and of their accuracy.
+
+
+
Multiplicity:
+
1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: verticalGeometryEstimatedAccuracy
+
+
+
+
+
+
+
+
+
Name:
+
Vertical geometry estimated accuracy
+
+
+
Value type:
+
Length
+
+
+
Definition:
+
The estimated absolute positional accuracy of the Z coordinates of the building geometry, in the INSPIRE official Coordinate Reference System. Absolute positional accuracy is defined as the mean value of the positional uncertainties for a set of positions where the positional uncertainties are defined as the distance between a measured position and what is considered as the corresponding true position.
+
+
+
Description:
+
NOTE This mean value may come from quality measures on a homogeneous population of buildings or from an estimation based on the knowledge of the production processes and of their accuracy.
This data type enables to detail the current use(s).
+
+
+
Stereotypes:
+
«dataType»
+
+
+
+
+
+
+
Attribute: currentUse
+
+
+
+
+
+
+
+
+
Name:
+
Current use
+
+
+
Value type:
+
CurrentUseValue
+
+
+
Definition:
+
The current use.
+
+
+
Description:
+
EXAMPLE: trade
+
+
+
Multiplicity:
+
1
+
+
+
+
+
+
+
Attribute: percentage
+
+
+
+
+
+
+
+
+
Name:
+
Percentage
+
+
+
Value type:
+
Integer
+
+
+
Definition:
+
The proportion of the real world object, given as a percentage, devoted to this current use.
+
+
+
Description:
+
NOTE The percentage of use is generally the percentage of floor area dedicated to this given use. If it is not the case, it is recommended to explain what the percentage refers to in metadata (template for additional information)
+EXAMPLE: 30 (if 30% of the building is occupied by trade activity).
+
+
+
Multiplicity:
+
1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Constraint: percentageSum
+
+
+
+
+
+
+
+
+
Natural language:
+
The total of all percentages shall be less or equal to 100.
+
+
+
OCL:
+
inv: self.percentage.sum()⇐100
+
+
+
+
+
+
+
+
+
5.3.2.2.6. ExternalReference
+
+
+
+
+
+
+
ExternalReference
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
External reference
+
+
+
Definition:
+
Reference to an external information system containing any piece of information related to the spatial object.
+
+
+
Stereotypes:
+
«dataType»
+
+
+
+
+
+
+
Attribute: informationSystem
+
+
+
+
+
+
+
+
+
Name:
+
Information system
+
+
+
Value type:
+
URI
+
+
+
Definition:
+
Uniform Resource Identifier of the external information system.
+
+
+
Multiplicity:
+
1
+
+
+
+
+
+
+
Attribute: informationSystemName
+
+
+
+
+
+
+
+
+
Name:
+
Information system name
+
+
+
Value type:
+
PT_FreeText
+
+
+
Definition:
+
The name of the external information system.
+
+
+
Description:
+
EXAMPLES: Danish Register of Dwellings, Spanish Cadastre.
+
+
+
Multiplicity:
+
1
+
+
+
+
+
+
+
Attribute: reference
+
+
+
+
+
+
+
+
+
Name:
+
Reference
+
+
+
Value type:
+
CharacterString
+
+
+
Definition:
+
Thematic identifier of the spatial object or of any piece of information related to the spatial object.
+
+
+
Description:
+
NOTE This reference will act as a foreign key to implement the association between the spatial object in the INSPIRE data set and in the external information system.
+EXAMPLE: The cadastral reference of a given building in the national cadastral register.
+
+
+
Multiplicity:
+
1
+
+
+
+
+
+
+
+
+
+
5.3.2.3. Code lists
+
+
5.3.2.3.1. ConditionOfConstructionValue
+
+
+
+
+
+
+
ConditionOfConstructionValue
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
Condition of construction value
+
+
+
Definition:
+
Values indicating the condition of a construction.
The allowed values for this code list comprise only the values specified in the INSPIRE Registry.
+
+
+
+
+
+
+
+
+
5.3.2.3.3. ElevationReferenceValue
+
+
+
+
+
+
+
ElevationReferenceValue
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
Elevation reference value
+
+
+
Definition:
+
List of possible elements considered to capture a vertical geometry.
+
+
+
Description:
+
NOTE The values of this code list are used to describe the reference of elevation both where elevation has been captured as attribute or as Z coordinate.
The allowed values for this code list comprise only the values specified in the INSPIRE Resgitry.
+
+
+
+
+
+
+
+
+
5.3.2.3.4. CurrentUseValue
+
+
+
+
+
+
+
CurrentUseValue
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
Current use value
+
+
+
Definition:
+
List of possible values indicating the current use.
+
+
+
Description:
+
SOURCE: This code list is partly based on and adapted from the Eurostat classification of types of constructions (for the classification of residential buildings).
+NOTE the values of this code list apply to buildings or building components where building components may be a building part (in core profiles) or a building unit (in extended profiles)
The allowed values for this code list comprise the values specified in the INSPIRE Registry and narrower values defined by data providers.
+
+
+
+
+
+
+
+
+
5.3.2.3.5. BuildingNatureValue
+
+
+
+
+
+
+
BuildingNatureValue
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
Building nature value
+
+
+
Definition:
+
Values indicating the nature of a building.
+
+
+
Description:
+
NOTE 1 : This code list does not aim to be exhaustive as the attribute buildingNature addresses only noticeable buildings.
+NOTE 2: The values included in this code list address mainly (but not only) two international use cases: air flights where buildings may be obstacles and marine navigation where buildings may be landmarks.
+NOTE 3: This code list should only be applied for buildings, even if it may be applicable to other constructions (for example, not all dams are buildings).
The allowed values for this code list comprise the values specified in the INSPIRE Registry and additional values at any level defined by data providers.
+
+
+
+
+
+
+
+
+
5.3.2.3.6. HorizontalGeometryReferenceValue
+
+
+
+
+
+
+
HorizontalGeometryReferenceValue
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
Horizontal geometry reference value
+
+
+
Definition:
+
Values indicating the element considered to capture a horizontal geometry.
The allowed values for this code list comprise only the values specified in the INSPIRE Registry.
+
+
+
+
+
+
+
+
+
+
5.3.2.4. Imported types (informative)
+
+
This section lists definitions for feature types, data types and code lists that are defined in other application schemas. The section is purely informative and should help the reader understand the feature catalogue presented in the previous sections. For the normative documentation of these types, see the given references.
+
+
+
5.3.2.4.1. Boolean
+
+
+
+
+
+
+
Boolean
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
Truth
+
+
+
Reference:
+
Geographic information — Conceptual schema language [ISO/TS 19103:2005]
+
+
+
+
+
+
+
+
+
5.3.2.4.2. CharacterString
+
+
+
+
+
+
+
CharacterString
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
Text
+
+
+
Reference:
+
Geographic information — Conceptual schema language [ISO/TS 19103:2005]
+
+
+
+
+
+
+
+
+
5.3.2.4.3. DateTime
+
+
+
+
+
+
+
DateTime
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
Date and Time
+
+
+
Reference:
+
Geographic information — Conceptual schema language [ISO/TS 19103:2005]
+
+
+
+
+
+
+
+
+
5.3.2.4.4. DirectPosition
+
+
+
+
+
+
+
DirectPosition
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
Coordinate geometry
+
+
+
Reference:
+
Geographic information — Spatial schema [ISO 19107:2003]
+
+
+
+
+
+
+
+
+
5.3.2.4.5. GM_Object
+
+
+
+
+
+
+
GM_Object (abstract)
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
Geometry root
+
+
+
Reference:
+
Geographic information — Spatial schema [ISO 19107:2003]
+
+
+
+
+
+
+
+
+
5.3.2.4.6. GeographicalName
+
+
+
+
+
+
+
GeographicalName
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
Geographical Names
+
+
+
Reference:
+
INSPIRE Data specification on Geographical Names [DS-D2.8.I.3]
+
+
+
Definition:
+
Proper noun applied to a real world entity.
+
+
+
+
+
+
+
+
+
5.3.2.4.7. Identifier
+
+
+
+
+
+
+
Identifier
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
Base Types
+
+
+
Reference:
+
INSPIRE Generic Conceptual Model, version 3.4 [DS-D2.5]
+
+
+
Definition:
+
External unique object identifier published by the responsible body, which may be used by external applications to reference the spatial object.
+
+
+
Description:
+
NOTE1 External object identifiers are distinct from thematic object identifiers.
+
+NOTE 2 The voidable version identifier attribute is not part of the unique identifier of a spatial object and may be used to distinguish two versions of the same spatial object.
+
+NOTE 3 The unique identifier will not change during the life-time of a spatial object.
+
+
+
+
+
+
+
+
+
5.3.2.4.8. Integer
+
+
+
+
+
+
+
Integer
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
Numerics
+
+
+
Reference:
+
Geographic information — Conceptual schema language [ISO/TS 19103:2005]
+
+
+
+
+
+
+
+
+
5.3.2.4.9. Length
+
+
+
+
+
+
+
Length
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
Units of Measure
+
+
+
Reference:
+
Geographic information — Conceptual schema language [ISO/TS 19103:2005]
+
+
+
+
+
+
+
+
+
5.3.2.4.10. PT_FreeText
+
+
+
+
+
+
+
PT_FreeText
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
Cultural and linguistic adapdability
+
+
+
Reference:
+
Geographic information — Metadata — XML schema implementation [ISO/TS 19139:2007]
+
+
+
+
+
+
+
+
+
5.3.2.4.11. URI
+
+
+
+
+
+
+
URI
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
basicTypes
+
+
+
Reference:
+
Geographic information — Geography Markup Language (GML) [ISO 19136:2007]
+
+
+
+
+
+
+
+
+
+
+
+
5.4. Application schema Buildings2D
+
+
5.4.1. Description
+
+
5.4.1.1. Narrative description
+
+
The Buildings 2D application schema inherits of the semantics of Buildings base application schema and defines the geometric representation of buildings and building parts, using the data type BuildingGeometry2D, also defined in the Buildings Base application schema.
+
+
+
+
+
+
+
+
Figure 25: The Buildings 2D application schema
+
+
+
Multiple geometries are allowed for buildings; for instance, a data producer may provide representation of a building as a surface and as a point or as several surfaces, e.g. the building captured by its foot print and by its roof edges.
+
+
+
NOTE : the 2D application schema requires that both the geometry of the Building and of BuildingPart have to be provided (multiplicity [1..*]). In some cases, the value "combined" may be used to provide the horizontal geometry reference of Building, as shown in following illustration.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
BuildingPart A was captured by its footprint.
+
+
+
BuildingPart B was captured by its lowest floor above ground.
+
+
+
The Building geometry was obtained by merging the geometries of A and B.
+
+
+
The horizontal geometry reference of the building will be combined.
+
+
+
+
+
+
Figure 26: Example for value "combined"
+
+
+
+
5.4.1.2. UML Overview
+
+
See previous Figure 25: The Buildings 2D application schema.
+
+
+
+
5.4.1.3. Consistency between spatial data sets
+
+
The 2D building geometry may be used as reference geometry by governmental services in INSPIRE theme US; if this option is chosen by the data provider of US theme, this will ensure consistency between themes BU and US and will enable users to find a more detailed classification of the buildings hosting public services.
+
+
+
+
5.4.1.4. Geometry representation
+
+
The geometric representation of buildings and building parts has to be provided using the data type BuildingGeometry2D that is defined in <Buildings Base> application schema. It is reminded that this spatial properties allowed in this data types are restricted to Simple Feature v1.2.1 as defined by OGC document 06-103r4, i.e. to 0D, 1D, 2D and 2,5D data.
+
+
+
+
+
+
📘
+
+
+
+
Recommendation 10
+There should not be topological overlaps between buildings having same temporal validity.
+
+
+
+
+
+
+
NOTE 1: Topological overlaps are the overlaps which occur in the dataset without occurring in the real world, i.e. the overlaps due to bad quality of data.
+
+
+
NOTE 2: Overlaps may occur in the data set between buildings and/or building parts, due to the 2D (or 2,5D) representation of 3D real world objects.
+
+
+
+
+
+
+
+
Figure 27: The 2D representations of these buildings are overlapping (this case of overlap is allowed)
+
+
+
+
+
+
📘
+
+
+
+
Recommendation 1
+The spatial objects Building should represent continuous or at least connected real world buildings, even if the representation may be done by a multi-surface.
+
+
+
+
+
+
+
+
+
+
+
+
Figure 28: Examples where multi-surface may be used
+
+
+
+
+
5.4.2. Feature catalogue
+
+
Feature catalogue metadata
+
+
+
+
+
+
+
+
+
Application Schema
+
INSPIRE Application Schema Buildings2D
+
+
+
Version number
+
3.0
+
+
+
+
+
Types defined in the feature catalogue
+
+
+
+
+
+
+
+
+
+
Type
+
Package
+
Stereotypes
+
+
+
+
+
Building
+
Buildings2D
+
«featureType»
+
+
+
BuildingPart
+
Buildings2D
+
«featureType»
+
+
+
+
+
5.4.2.1. Spatial object types
+
+
5.4.2.1.1. Building
+
+
+
+
+
+
+
Building
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
Building
+
+
+
Subtype of:
+
Building
+
+
+
Definition:
+
A Building is an enclosed construction above and/or underground, used or intended for the shelter of humans, animals or things or for the production of economic goods. A building refers to any structure permanently constructed or erected on its site.
+
+
+
Stereotypes:
+
«featureType»
+
+
+
+
+
+
+
Attribute: geometry2D
+
+
+
+
+
+
+
+
+
Name:
+
Geometry 2D
+
+
+
Value type:
+
BuildingGeometry2D
+
+
+
Definition:
+
2D or 2.5D geometric representation of the building.
+
+
+
Description:
+
NOTE Multiple representations of the geometry are possible (e.g. by surface and by point).
+
+
+
Multiplicity:
+
1
+
+
+
+
+
+
+
Constraint: Building parts shall be 2D
+
+
+
+
+
+
+
+
+
Natural language:
+
The parts of the building shall be represented using the BuildingPart type of the Buildings2D package.
A BuildingPart is a sub-division of a Building that might be considered itself as a building.
+
+
+
Description:
+
NOTE 1: A BuildingPart is homogeneous related to its physical, functional or temporal aspects.
+
+NOTE 2: Building and BuildingPart share the same set of properties.
+EXAMPLE: A building may be composed of two building parts having different heights above ground.
+
+
+
Stereotypes:
+
«featureType»
+
+
+
+
+
+
+
Attribute: geometry2D
+
+
+
+
+
+
+
+
+
Name:
+
Geometry 2D
+
+
+
Value type:
+
BuildingGeometry2D
+
+
+
Definition:
+
2D or 2.5D geometric representation of the building part.
+
+
+
Description:
+
NOTE Multiple representations of the geometry are possible (e.g. by surface and by point).
+
+
+
Multiplicity:
+
1..*
+
+
+
+
+
+
+
Constraint: singleReferenceGeometry
+
+
+
+
+
+
+
+
+
Natural language:
+
Exactly one geometry2D attribute must be a reference geometry, i.e. the referenceGeometry attribute must be 'true'.
This section lists definitions for feature types, data types and code lists that are defined in other application schemas. The section is purely informative and should help the reader understand the feature catalogue presented in the previous sections. For the normative documentation of these types, see the given references.
+
+
+
5.4.2.2.1. BuildingGeometry2D
+
+
+
+
+
+
+
BuildingGeometry2D
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
BuildingsBase
+
+
+
Reference:
+
INSPIRE Data specification on Buildings [DS-D2.8.III.2]
+
+
+
Definition:
+
This data types includes the geometry of the building and metadata information about which element of the building was captured and how.
+
+
+
+
+
+
+
+
+
+
+
+
5.5. Application schema Buildings3D
+
+
5.5.1. Description
+
+
5.5.1.1. Narrative description
+
+
The Buildings 3D application schema is a normative profile offered to data producers of 3D building data, in order to enable them to be INSPIRE conformant without having to "flatten" their data geometrically.
+
+
+
5.5.1.1.1. Feature types
+
+
The Buildings 3D application schema inherits of the semantics of <Buildings base> application schema and defines the geometric representation of buildings and building parts:
+
+
+
+
+
The 3D representation has to be provided, using any of the LoD of City GML
+
+
+
A 2D (or 2,5D) representation is allowed by the voidable attribute geometry2D
+
+
+
+
+
+
+
+
+
+
Figure 29: The Buildings 3D application schema
+
+
+
Buildings and building parts may be represented using any of the four levels of detail of City GML:
+
+
+
+
+
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"
+
+
+
in LoD2, a Building or BuildingPart is represented by a generalised way with vertical lateral surfaces and a prototypical roof or cover shape
+
+
+
inLod3 and LoD4, a Building or BuildingPart is represented by its real detailed shape for lateral faces (including protrusions, facade elements, and window recesses) as well as of the roof (including dormers, chimneys)
+
+
+
+
+
NOTE 1: The outer geometry of buildings in LoD3 and LoD4 is the same.
+
+
+
NOTE 2: the Buildings3D model allows to provide the four levels of City GML. However, it is very likely that data producers having LoD3 or LoD4 data will have more information about buildings than the content of this profile (e.g. description of the boundary surfaces, textures). In this case, the extended 3D profile will be more relevant.
+
+
+
The representation of Buildings in INSPIRE is based on the 4 levels of detail of City GML.
+
+
+
+
+
+
+
+
Figure 30: The 4 levels of detail of City GML
+
+
+
This means that it is possible, for instance:
+
+
+
+
+
to choose one LoD and to use it for all buildings in the data set
+
+
+
to use, in same data set, LoD1 for some buildings, LoD2 for some others and LoD3 or LoD4 for the last ones.
+
+
+
to have, in same data set, several representations for the same building (e.g. one in LoD2 and one in LoD3)
+
+
+
+
+
Typically, in many existing data, ordinary buildings are represented using LoD1 or LoD2 whereas noticeable buildings or buildings in a project area will be represented with more details (LoD2, LoD3 or even LoD4).
+
+
+
The Buildings3D application schema only imposes that, at least, one of the mandatory geometries (i.e. LoD1, 2, 3 or 4 as solid or as multi-surface) is provided. This is indicated by a constraint.
+
+
+
+
+
+
+
+
Figure 31: Geometry may be only on BuildingParts
+
+
+
In opposite to core 2D profile, duplication of geometry is not required in case of a building having building parts: the 3D geometry has to be provided on the building parts (constraint {MandatoryGeometry}) but is optional on the building. Of course, a simple building without any building part has a mandatory geometry (constraint {GeometryWhenNoParts}).
+
+
+
NOTE the constraints "building parts shall be 3D" means that the building parts composing the buildings shall come to same application schema <Buildings 3D> and not from the <Buildings Base> application schema, i.e. the building parts shall have a 3D geometric representation.
+
+
+
+
5.5.1.1.2. Data types for 3D building geometry
+
+
+
+
+
+
+
Figure 32: The data type BuildingGeometry3DLoD
+
+
+
For each level of detail of CityGML, the building or building part shall be represented either as a GM_Solid or as a GM_MultiSurface. If the representation as GM_Solid is chosen, the Building (or BuildingPart) is completely sealed by (non-overlapping) polygons in a topologically clean manner. This representation in general has the advantage that the volume can be computed. This is necessary, for example, in disaster management applications to compute the volume of remaining breathing air or in environmental applications for the computation of energy related features. However, often such topologically clean models are not available in practice. This typically is the case if the data is captured by photogrammetric methods and particularly, the ground surface of the buildings (which is not observable by such methods) is missing. To accommodate for those models, the GM_MultiSurface representation is allowed.
+
+
+
+
+
+
+
+
Figure 33: LoD 1 representation of a building as GM_Solid (a) and as GM_MultiSurface (b).
+
+
+
In both cases, the upper polygon (depicted hatched green) and the base geometry (blue) are horizontal. The side surfaces (grey) are rectangular and vertical. In the case of a GM_MultiSurface representation, the base polygon (depicted hatched blue) is missing.
+
+
+
In addition to the representation of a building by its outer shell in the four LoDs of City GML, the intersection of the building with the terrain may be provided, as a line.
+
+
+
+
+
+
+
+
Figure 34: The terrain intersection is shown in black
+
+
+
Moreover, the 3D geometry of the building or building part has to be documented.
+
+
+
For all LoDs, the level of building that was chosen to represent its bottom, has to be documented, through the attribute verticalGeometryReference3DBottom and using preferably the following values from the code list ElevationReferenceValue:
+
+
+
+
+
generalGround
+
+
+
lowestGroundPoint
+
+
+
bottomOfConstruction
+
+
+
lowestFloorAboveGround
+
+
+
highestGroundPoint
+
+
+
+
+
Moreover, in case of Lod1 and LoD2, the representation of the building is only a generalised representation. So, as in core 2D profile, the horizontal geometry reference (that is the base for extrusion of the 3D geometry) has to be documented
+
+
+
The code list used to document the horizontal geometry reference is the same as in core 2D profile but the point references are not allowed (as a point horizontal geometry would not enable to represent the building as a volume). This is indicated by the constraint { NoPointReferencingIn3D }. In other words, only the values footprint, lowestFloorAboveGround, roofEdge, envelopeAboveGround and envelope may be used.
+
+
+
NOTE1: The horizontal geometry reference is not necessary for LoD3 and LoD4 where the 3D geometry shall represent the exact and detailed shape of the building. It is why this attribute is specific to LoD1 and LoD2.
+
+
+
NOTE 2: the value "combined" is not really suitable for 3D geometry, as the geometry of the building is optional when the building is the combination of several building parts.
+
+
+
Moreover, in case of LoD1 representation, the level of building that was chosen to represent its top, has to be documented, through the attribute verticalGeometryReference3DTop and using preferably the following values from the code list ElevationReferenceValue:
+
+
+
+
+
generalRoofEdge
+
+
+
lowestRoofEdge
+
+
+
highestRoofEdge
+
+
+
lowestEave
+
+
+
generalEave
+
+
+
highestEave
+
+
+
generalRoof
+
+
+
top OfConstruction
+
+
+
+
+
This information is not necessary for the other LoDs of City GML where the building or building part is represented with its roof. It is why this attribute is specific to LoD1.
+
+
+
+
+
+
+
+
Figure 35: The 3D geometry of Building and BuildingPart has to be documented (example of LoD1)
+
+
+
+
+
5.5.1.2. UML Overview
+
+
+
+
+
+
+
Figure 36: UML overview of Buildings Core 3D
+
+
+
+
5.5.1.3. Consistency between spatial data sets
+
+
It will be meaningful to use Buidings 3D data (when available) with INSPIRE themes taking also into account the vertical dimension, such as theme Elevation.
+
+
+
+
5.5.1.4. Modelling of object references
+
+
The external reference may be used as in core 2D profile. Moreover, in case the 2D (or 2,5D) representation of the building used to construct the 3D representation is not in the same data set as the 3D representation, the external reference may be used to link the spatial object in 3D data base to the 2D object representing the same building.
+
+
+
EXAMPLE: a local government has produced 3D data of buildings, using the 2D geometry provided by the national Cadastre. The external reference to the national cadastral system would enable users to know that these two related spatial objects represent the same real world building and would facilitate consistency between these various views on buildings.
+
+
+
+
5.5.1.5. Geometry representation
+
+
Art. 12(1) of Regulation 1089/2010 restricts the value domain of spatial properties to the Simple Feature spatial schema as defined in the OpenGIS® Implementation Standard for Geographic information – Simple feature access – Part 1: Common architecture, version 1.2.1, unless specified otherwise for a specific spatial data theme or type.
+
+
+
+
+
+
📕
+
+
+
+
IR Requirement
+Section 2.4
+Theme-specific Requirement
+
+
+
By way of derogation from article 12(1), the value domain of spatial properties used in the Buildings 3D package shall not be restricted.
+
+
+
+
+
+
+
NOTE2: The topological relations of two spatial objects based on their specific geometry and topology properties can in principle be investigated by invoking the operations of the types defined in ISO 19107 (or the methods specified in EN ISO 19125-1).
+
+
+
+
+
+
📘
+
+
+
+
Recommendation 11
+
+
+
There should not be penetration between buildings and/or building parts having same temporal validity.
+
+
+
+
+
+
+
NOTE buildings and/or building parts may be touching (e.g. through common wall) but should not share common volume.
+
+
+
+
+
5.5.2. Feature catalogue
+
+
Feature catalogue metadata
+
+
+
+
+
+
+
+
+
Application Schema
+
INSPIRE Application Schema Buildings3D
+
+
+
Version number
+
3.0
+
+
+
+
+
Types defined in the feature catalogue
+
+
+
+
+
+
+
+
+
+
Type
+
Package
+
Stereotypes
+
+
+
+
+
Building
+
Buildings3D
+
«featureType»
+
+
+
BuildingGeometry3DLoD
+
Buildings3D
+
«dataType»
+
+
+
BuildingGeometry3DLoD1
+
Buildings3D
+
«dataType»
+
+
+
BuildingGeometry3DLoD2
+
Buildings3D
+
«dataType»
+
+
+
BuildingPart
+
Buildings3D
+
«featureType»
+
+
+
+
+
5.5.2.1. Spatial object types
+
+
5.5.2.1.1. Building
+
+
+
+
+
+
+
Building
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
Building
+
+
+
Subtype of:
+
Building
+
+
+
Definition:
+
A Building is an enclosed construction above and/or underground, used or intended for the shelter of humans, animals or things or for the production of economic goods. A building refers to any structure permanently constructed or erected on its site.
+
+
+
Stereotypes:
+
«featureType»
+
+
+
+
+
+
+
Attribute: geometry2D
+
+
+
+
+
+
+
+
+
Name:
+
geometry 2D
+
+
+
Value type:
+
BuildingGeometry2D
+
+
+
Definition:
+
<font color="#0f0f0f">2D or 2.5D geometric representation. <font color="#0f0f0f"> <font color="#0f0f0f">
+
+
+
Description:
+
<font color="#0f0f0f">NOTE Multiple representations of the geometry are possible (e.g. by surface and by point).
+
+
+
Multiplicity:
+
0..*
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: geometry3DLoD1
+
+
+
+
+
+
+
+
+
Name:
+
geometry 3D LoD 1
+
+
+
Value type:
+
BuildingGeometry3DLoD1
+
+
+
Definition:
+
3D geometric representation at level of detail (LoD) 1, consisting of the generalized representation of the outer boundary by vertical lateral surfaces and horizontal base polygons.
+
+
+
Multiplicity:
+
0..1
+
+
+
+
+
+
+
Attribute: geometry3DLoD2
+
+
+
+
+
+
+
+
+
Name:
+
geometry 3D LoD 2
+
+
+
Value type:
+
BuildingGeometry3DLoD2
+
+
+
Definition:
+
3D geometric representation at level of detail (LoD) 2, consisting of the generalized representation of the outer boundary by vertical lateral surfaces and a prototypical roof shape or cover (from a defined list of roof shapes)
+
+
+
Description:
+
NOTE The prototypical roof shapes come from a defined list of roof shapes, in City GML; this list is equivalent to the code list RoofTypeValue, provided in the extended2D profile (without the hyperbolic parabaloidal roof).
+
+
+
Multiplicity:
+
0..1
+
+
+
+
+
+
+
Attribute: geometry3DLoD3
+
+
+
+
+
+
+
+
+
Name:
+
geometry 3D LoD 3
+
+
+
Value type:
+
BuildingGeometry3DLoD
+
+
+
Definition:
+
3D geometric representation at level of detail (LoD) 3, consisting of the detailed representation of the outer boundary (including protrusions, facade elements and window recesses) as well as of the roof shape (including dormers, chimneys).
+
+
+
Multiplicity:
+
0..1
+
+
+
+
+
+
+
Attribute: geometry3DLoD4
+
+
+
+
+
+
+
+
+
Name:
+
geometry 3D LoD 4
+
+
+
Value type:
+
BuildingGeometry3DLoD
+
+
+
Definition:
+
3D geometric representation at level of detail (LoD) 4, consisting of the detailed representation of the outer boundary (including protrusions, facade elements, and window recesses) as well as of the roof shape (including dormers, chimneys).
+
+
+
Description:
+
NOTE The LoD4 representation is equivalent to the LoD3 representation in core 3D application schema. The LoD 4 representation is more meaningful in extended 3D application schema, with the optional description of building interior.
+
+
+
Multiplicity:
+
0..1
+
+
+
+
+
+
+
Constraint: Building parts shall be 3D
+
+
+
+
+
+
+
+
+
Natural language:
+
The parts of the building shall be represented using the BuildingPart type of the Buildings3D package.
If a Building does not have any BuildingParts, at least the geometry3DLoD1 or geometry3DLoD2 or geometry3DLoD3 or geometry3DLoD4 attributes shall be provided.
+
+
+
OCL:
+
+
+
+
+
+
+
+
+
+
5.5.2.1.2. BuildingPart
+
+
+
+
+
+
+
BuildingPart
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
Building part
+
+
+
Subtype of:
+
BuildingPart
+
+
+
Definition:
+
A BuildingPart is a sub-division of a Building that might be considered itself as a building.
+
+
+
Description:
+
NOTE 1: A building part is homogeneous related to its physical, functional and temporal aspects.
+
+EXAMPLE: A building may be composed of two building parts having different heights above ground.
+
+
+
Stereotypes:
+
«featureType»
+
+
+
+
+
+
+
Attribute: geometry2D
+
+
+
+
+
+
+
+
+
Name:
+
geometry 2D
+
+
+
Value type:
+
BuildingGeometry2D
+
+
+
Definition:
+
<font color="#0f0f0f">2D or 2.5D geometric representation. <font color="#0f0f0f"> <font color="#0f0f0f">
+
+
+
Description:
+
<font color="#0f0f0f">NOTE Multiple representations of the geometry are possible (e.g. by surface and by point).
+
+
+
Multiplicity:
+
0..*
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: geometry3DLoD1
+
+
+
+
+
+
+
+
+
Name:
+
geometry 3D LoD 1
+
+
+
Value type:
+
BuildingGeometry3DLoD1
+
+
+
Definition:
+
3D geometric representation at level of detail (LoD) 1, consisting of the generalized representation of the outer boundary by vertical lateral surfaces and horizontal base polygons.
+
+
+
Multiplicity:
+
0..1
+
+
+
+
+
+
+
Attribute: geometry3DLoD2
+
+
+
+
+
+
+
+
+
Name:
+
geometry 3D LoD 2
+
+
+
Value type:
+
BuildingGeometry3DLoD2
+
+
+
Definition:
+
3D geometric representation at level of detail (LoD) 2, consisting of the generalized representation of the outer boundary by vertical lateral surfaces and a prototypical roof shape or cover (from a defined list of roof shapes). NOTE The prototypical roof shapes come from a defined list of roof shapes, in City GML; this list is equivalent to the code list RoofTypeValue, provided in the extended2D profile (without the hyperbolic parabaloidal roof).
+
+
+
Multiplicity:
+
0..1
+
+
+
+
+
+
+
Attribute: geometry3DLoD3
+
+
+
+
+
+
+
+
+
Name:
+
geometry 3D LoD 3
+
+
+
Value type:
+
BuildingGeometry3DLoD
+
+
+
Definition:
+
3D geometric representation at level of detail (LoD) 3, consisting of the detailed representation of the outer boundary (including protrusions, facade elements and window recesses) as well as of the roof shape (including dormers, chimneys).
+
+
+
Multiplicity:
+
0..1
+
+
+
+
+
+
+
Attribute: geometry3DLoD4
+
+
+
+
+
+
+
+
+
Name:
+
geometry 3D LoD 4
+
+
+
Value type:
+
BuildingGeometry3DLoD
+
+
+
Definition:
+
3D geometric representation at level of detail (LoD) 4, consisting of the detailed representation of the outer boundary (including protrusions, facade elements, and window recesses) as well as of the roof shape (including dormers, chimneys).
+
+
+
Description:
+
NOTE The LoD4 representation is equivalent to the LoD3 representation in core 3D application schema. The LoD 4 representation is more meaningful in extended 3D application schema, with the optional description of building interior.
+
+
+
Multiplicity:
+
0..1
+
+
+
+
+
+
+
Constraint: MandatoryGeometry
+
+
+
+
+
+
+
+
+
Natural language:
+
At least one of the geometry3DLoD1 or geometry3DLoD2 or geometry3DLoD3 or geometry3DLoD4 attributes shall be provided.
+
+
+
OCL:
+
+
+
+
+
+
+
+
+
+
+
5.5.2.2. Data types
+
+
5.5.2.2.1. BuildingGeometry3DLoD
+
+
+
+
+
+
+
BuildingGeometry3DLoD
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
Building geometry 3D LoD
+
+
+
Definition:
+
Data type grouping the 3D geometry of a building or building part and the metadata information attached to this geometry.
+
+
+
Stereotypes:
+
«dataType»
+
+
+
+
+
+
+
Attribute: geometryMultiSurface
+
+
+
+
+
+
+
+
+
Name:
+
Geometry multi-surface
+
+
+
Value type:
+
GM_MultiSurface
+
+
+
Definition:
+
Representation of the outer boundary by a Multi Surface, which may - in contrast to a solid representation - not be topologically clean. In particular, the ground surface may be missing.
+
+
+
Multiplicity:
+
0..1
+
+
+
+
+
+
+
Attribute: geometrySolid
+
+
+
+
+
+
+
+
+
Name:
+
Geometry solid
+
+
+
Value type:
+
GM_Solid
+
+
+
Definition:
+
Representation of the outer boundary by a solid.
+
+
+
Multiplicity:
+
0..1
+
+
+
+
+
+
+
Attribute: terrainIntersection
+
+
+
+
+
+
+
+
+
Name:
+
Terrain intersection
+
+
+
Value type:
+
GM_MultiCurve
+
+
+
Definition:
+
Line or multi-line where the spatial object (Building, BuildingPart, …) touches the terrain representation.
+
+
+
Multiplicity:
+
0..1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: verticalGeometryReference3DBottom
+
+
+
+
+
+
+
+
+
Name:
+
Vertical geometry reference 3D bottom
+
+
+
Value type:
+
ElevationReferenceValue
+
+
+
Definition:
+
Height level to which the lower height of the model (Z-value of the lower horizontal polygon) refers to.
+
+
+
Description:
+
EXAMPLE: generalGround, bottomOfConstruction.
+
+
+
Multiplicity:
+
0..1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: horizontalGeometryEstimatedAccuracy
+
+
+
+
+
+
+
+
+
Name:
+
Horizontal geometry estimated accuracy
+
+
+
Value type:
+
Length
+
+
+
Definition:
+
The estimated absolute positional accuracy of the (X,Y) coordinates of the geometry, in the INSPIRE official Coordinate Reference System. Absolute positional accuracy is defined as the mean value of the positional uncertainties for a set of positions where the positional uncertainties are defined as the distance between a measured position and what is considered as the corresponding true position.
+
+
+
Description:
+
NOTE this mean value may come from quality measures on a homogeneous population of buildings or from an estimation based on the knowledge of the production processes and of their accuracy.
+
+
+
Multiplicity:
+
0..1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: verticalGeometryEstimatedAccuracy
+
+
+
+
+
+
+
+
+
Name:
+
Vertical geometry estimated accuracy
+
+
+
Value type:
+
Length
+
+
+
Definition:
+
The estimated absolute positional accuracy of the Z- coordinate of the geometry, in the INSPIRE official Coordinate Reference System. Absolute positional accuracy is defined as the mean value of the positional uncertainties for a set of positions where the positional uncertainties are defined as the distance between a measured position and what is considered as the corresponding true position.
+
+
+
Description:
+
NOTE this mean value may come from quality measures on a homogeneous population of buildings or from an estimation based on the knowledge of the production processes and of their accuracy.
+
+
+
Multiplicity:
+
0..1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Constraint: oneGeometryToBeProvided
+
+
+
+
+
+
+
+
+
Natural language:
+
Either the geometryMultiSurface or the geometrySolid attribute shall be provided.
+
+
+
OCL:
+
inv: self.geometryMultiSurface→notEmpty() or self.geometrySolid→notEmpty()
+
+
+
+
+
+
+
+
+
5.5.2.2.2. BuildingGeometry3DLoD1
+
+
+
+
+
+
+
BuildingGeometry3DLoD1
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
Building geometry 3D LoD 1
+
+
+
Subtype of:
+
BuildingGeometry3DLoD
+
+
+
Definition:
+
Data type grouping the specific metadata attached to the 3D geometry, when provided by a LoD 1 representation.
+
+
+
Stereotypes:
+
«dataType»
+
+
+
+
+
+
+
Attribute: horizontalGeometryReference
+
+
+
+
+
+
+
+
+
Name:
+
Horizontal geometry reference
+
+
+
Value type:
+
HorizontalGeometryReferenceValue
+
+
+
Definition:
+
Element of the real world object that was captured by the (X,Y) coordinates of the LoD1 Multisurface or Solid geometry.
+
+
+
Description:
+
EXAMPLE: footprint, roof edge
+
+
+
Multiplicity:
+
0..1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: verticalGeometryReference3DTop
+
+
+
+
+
+
+
+
+
Name:
+
Vertical geometry reference 3D top
+
+
+
Value type:
+
ElevationReferenceValue
+
+
+
Definition:
+
Height level to which the upper height of the model (Z-value of the upper horizontal polygon) refers to.
+
+
+
Description:
+
EXAMPLE: generalRoof, lowestRoof Edge.
+
+
+
Multiplicity:
+
0..1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Constraint: no point referencing in 3D
+
+
+
+
+
+
+
+
+
Natural language:
+
The horizontalGeometryReference attribute shall not take the value entrancePoint, pointInsideBuilding or pointInsideCadastralParcel.
This section lists definitions for feature types, data types and code lists that are defined in other application schemas. The section is purely informative and should help the reader understand the feature catalogue presented in the previous sections. For the normative documentation of these types, see the given references.
+
+
+
5.5.2.3.1. BuildingGeometry2D
+
+
+
+
+
+
+
BuildingGeometry2D
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
BuildingsBase
+
+
+
Reference:
+
INSPIRE Data specification on Buildings [DS-D2.8.III.2]
+
+
+
Definition:
+
This data types includes the geometry of the building and metadata information about which element of the building was captured and how.
+
+
+
+
+
+
+
+
+
5.5.2.3.2. ElevationReferenceValue
+
+
+
+
+
+
+
ElevationReferenceValue
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
BuildingsBase
+
+
+
Reference:
+
INSPIRE Data specification on Buildings [DS-D2.8.III.2]
+
+
+
Definition:
+
List of possible elements considered to capture a vertical geometry.
+
+
+
Description:
+
NOTE The values of this code list are used to describe the reference of elevation both where elevation has been captured as attribute or as Z coordinate.
+
+
+
+
+
+
+
+
+
5.5.2.3.3. GM_MultiCurve
+
+
+
+
+
+
+
GM_MultiCurve
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
Geometric aggregates
+
+
+
Reference:
+
Geographic information — Spatial schema [ISO 19107:2003]
+
+
+
+
+
+
+
+
+
5.5.2.3.4. GM_MultiSurface
+
+
+
+
+
+
+
GM_MultiSurface
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
Geometric aggregates
+
+
+
Reference:
+
Geographic information — Spatial schema [ISO 19107:2003]
+
+
+
+
+
+
+
+
+
5.5.2.3.5. GM_Solid
+
+
+
+
+
+
+
GM_Solid
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
Geometric primitive
+
+
+
Reference:
+
Geographic information — Spatial schema [ISO 19107:2003]
+
+
+
+
+
+
+
+
+
5.5.2.3.6. HorizontalGeometryReferenceValue
+
+
+
+
+
+
+
HorizontalGeometryReferenceValue
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
BuildingsBase
+
+
+
Reference:
+
INSPIRE Data specification on Buildings [DS-D2.8.III.2]
+
+
+
Definition:
+
Values indicating the element considered to capture a horizontal geometry.
+
+
+
+
+
+
+
+
+
5.5.2.3.7. Length
+
+
+
+
+
+
+
Length
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
Units of Measure
+
+
+
Reference:
+
Geographic information — Conceptual schema language [ISO/TS 19103:2005]
+
+
+
+
+
+
+
+
+
+
+
+
5.6. Application schema BuildingsExtendedBase
+
+
5.6.1. Description
+
+
5.6.1.1. Narrative description
+
+
Buildings Base Extended is an abstract application schema describing the additional semantics that is common to instanciable application schemas Buildings Extended2D and Buildings Extended3D.
+
+
+
5.6.1.1.1. Additional feature types
+
+
+
+
+
+
+
Figure 37: Main feature types of Buildings Base Extended
+
+
+
The Buildings BaseExtended contains mainly 3 new feature types:
+
+
+
+
+
OtherConstructions are self-standing constructions that are generally not considered as buildings. This extended profile includes the most significant constructions that are necessary to describe landscape and to fulfil use cases such as safety or spatial planning.
+
+
+
Installations are constructions, generally of small size that are attached to a Building (or a BuildingPart).
+
+
+
BuildingUnits are subdivisions of Building with their own lockable access from the outside or from a common area (i.e. not from another BuildingUnit), which are atomic, functionally independent, and may be separately sold, rented out, inherited, etc.
+
+
+
+
+
A building unit is homogeneous for management aspects. Its key mandatory attribute is the external reference to some official register where the BuildingUnit is identified and described. It is generally the cadastral register but may be another information system, e.g. a register of public properties.
+
+
+
+
5.6.1.1.2. Other Constructions
+
+
Other constructions inherit of the attributes of AbstractConstruction (from <BuildingsBase> ) and are mainly described by their nature, that may take following values:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
acousticFence
+
antenna
+
chimney
+
bridge
+
bridge
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
cityWall
+
crane
+
monument
+
monument
+
monument
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
monument
+
monument
+
openAirPool
+
protectiveStructure
+
protectiveStructure
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
pylon
+
retainingWall
+
solarPanel
+
substation
+
tunnel
+
+
+
+
+
Figure 38: Illustrations of other constructions
+
+
+
+
5.6.1.1.3. Installations
+
+
Installations inherit of the attributes of AbstractConstruction (from <BuildingsBase> ) and are mainly described by their nature, that may take the following values.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
airConditioningUnit
+
airDuct
+
antenna
+
antenna
+
arcade
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
balcony
+
chimney
+
chimney
+
cradle
+
dormer
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
externalLift
+
railing
+
ramp
+
solarPanel
+
stairway
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
stairway
+
stairway
+
tower
+
windTurbine
+
windTurbine
+
+
+
+
+
Figure 39: Illustrations for of installation nature
+
+
+
NOTE 1: The list of installation nature does not aim to be exhaustive but focus on the installations related to safety and on environmental issues (mainly energy).
+
+
+
NOTE 2: The code list for installation nature is the same for extended 2D and extended 3D data. However, likely, some values will be used only for 3D data (e.g. dormer, arcade, balcony).
+
+
+
+
5.6.1.1.4. New properties
+
+
+
+
+
+
+
Figure 40: The new properties of buildings / building parts
+
+
+
Buildings BaseExtended defines additional properties that will apply to buildings and building parts in application schema Extended2D and Extended3D.
+
+
+
These additional properties are gathered in two abstract feature types BuildingAndBuildingUnitInfo and BuildingInfo.
+
+
+
NOTE these two new classes are just container for the additional attributes and associations rather than real feature types.
+
+
+
+
+
The additional properties that are common to buildings, building parts and building units are grouped in feature type BuildingAndBuildingUnitInfo. These common attributes are mainly related to official information. In addition to the common attributes shown in the figure below, BuildingAndBuildingUnitInfo has associations to feature types Address and Cadastral Parcels that are in annex I themes.
+
+
+
+
+
+
+
+
+
+
Figure 41: Common additional attributes of buildings, building parts and building units
+
+
+
+
+
The additional properties that are specific to buildings and building parts are grouped in feature type BuildingInfo. These attributes address the physical description with more details than in the <Buildings Base> application schema.
+
+
+
+
+
+
+
+
+
+
Figure 42: Common additional attributes to buildings and building parts
+
+
+
+
5.6.1.1.5. Attribute roofType
+
+
This attribute may take the following values:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
flatRoof
+
monopitchRoof
+
gabledRoof
+
hippedRoof
+
MansardRoof
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
halfHippedRoof
+
coneRoof
+
pyramidalBroachRoof
+
copulaRoof
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
archRoof
+
dualPentRoof
+
sawToothRoof
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
pavilionRoof
+
hyperbolicParabaloidalRoof
+
+
+
+
+
+
Figure 43: Roof types (most illustrations from 3D GIS)
+
+
+
+
5.6.1.1.6. Attribute MaterialOfStructure
+
+
This attribute may take the following values:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
adobeBlockWalls
+
concreteBlockMasonry
+
earth
+
firedBrickMasonry
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
informalConstructions
+
massiveStoneMasonry
+
mobileHomes
+
mudWalls
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
precastConcrete
+Tilt-upWalls
+
+
reinforcedConcrete
+
reinforcedMasonry
+
rubleStoneMasonry
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
steel
+
stoneMasonryBlock
+
wood
+
wood
+
+
+
+
+
Figure 44: Illustrations for material of structure
+
+
+
+
5.6.1.1.7. MaterialOfFacade
+
+
This attribute may take the following values:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
adobe
+
asbestos
+
ceramicTiles
+
composite
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
concrete
+
glass
+
limestone
+
masonry
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
metal
+
naturalStone
+
vegetated
+
wood
+
+
+
+
+
Figure 45: Illustrations for material of facade
+
+
+
+
5.6.1.1.8. MaterialOfRoof
+
+
This attribute may take the following values:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
asbestos
+
ceramicTiles
+
clayTile
+
composition
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
concreteTile
+
corrugatedSheet
+
glass
+
hotMoppedAsphalt
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
metal
+
reinforcedConcrete
+
slate
+
slate
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
thatch
+
thatch
+
vegetatedRoof
+
+
woodShingles
+OrShakes
+
+
+
+
+
+
Figure 46: Illustrations for material of roof
+
+
+
+
5.6.1.1.9. Attribute Document
+
+
The INSPIRE model allows the possibility to link documents to a building or a building part or a floor or a building unit; various documents may be concerned, such as images, sketches, building permits, emergency plans ….. . The attribute Document is defined as a data type with the link to the place the document may be found and with a simple set of metadata elements.
+
+
+
+
+
+
+
+
Figure 47: The data type Document
+
+
+
+
+
+
📘
+
+
+
+
Recommendation 1
+
+
+
Documents should be provided in well-known and easy to handle formats.
+
+
+
+
+
+
+
EXAMPLE: documents may be provided in .PDF, .TIF (or geotif), .JPEG, .BMP, .PNG._
+
+
+
NOTE 1: Formats whose content is unknown to user, such as .EXE or .ZIP should be avoided.
+
+
+
NOTE 2: The documents related to the regulations that apply on all buildings in an area of interest (e.g. land use zone, regulated area, protected site) may and should rather be provided in the respective other INSPIRE themes.
+
+
+
+
5.6.1.1.10. Attribute officialValue
+
+
The attribute official value may be submitted to access restrictions due for instance to privacy issues. Consequently, the INSPIRE model allows this information to be provided, either directly by its value and currency or indirectly by the external reference to another information system. In first case, the access to the information of official area is widely open, following INSPIRE rules. In the second case, the access to the other external information system may be restricted to authorized users.
+
+
+
In addition to the official value itself, some metadata elements should be provided in order to indicate what the official value represents.
+
+
+
+
+
+
+
+
Figure 48: The data type OfficialValue
+
+
+
+
+
+
+
+
Figure 49: The mechanism to get official value through external reference to another information
+
+
+
NOTE The mechanism to provide value of an attribute either directly or through the reference to another information system may be used by data providers for other attributes, in case they are submitted to access restrictions.
+
+
+
+
+
5.6.1.2. UML Overview
+
+
+
+
+
+
+
Figure 50: Overview of BuildingExtendedBase
+
+
+
+
+
+
+
+
Figure 51: Overview of BuildingExtendedBase - Data Types
+
+
+
+
+
+
+
+
Figure 52: Overview of BuildingExtendedBase - Code lists
+
+
+
+
+
5.6.2. Feature catalogue
+
+
Feature catalogue metadata
+
+
+
+
+
+
+
+
+
Application Schema
+
INSPIRE Application Schema BuildingsExtendedBase
+
+
+
Version number
+
3.0
+
+
+
+
+
Types defined in the feature catalogue
+
+
+
+
+
+
+
+
+
+
Type
+
Package
+
Stereotypes
+
+
+
+
+
AbstractBuildingUnit
+
BuildingsExtendedBase
+
«featureType»
+
+
+
AbstractInstallation
+
BuildingsExtendedBase
+
«featureType»
+
+
+
AbstractOtherConstruction
+
BuildingsExtendedBase
+
«featureType»
+
+
+
BuildingAndBuildingUnitInfo
+
BuildingsExtendedBase
+
«featureType»
+
+
+
BuildingInfo
+
BuildingsExtendedBase
+
«featureType»
+
+
+
CLGE_OfficialAreaReferenceValue
+
BuildingsExtendedBase
+
«codeList»
+
+
+
CurrencyValue
+
BuildingsExtendedBase
+
«codeList»
+
+
+
Document
+
BuildingsExtendedBase
+
«dataType»
+
+
+
EnergyPerformance
+
BuildingsExtendedBase
+
«dataType»
+
+
+
EnergyPerformanceValue
+
BuildingsExtendedBase
+
«codeList»
+
+
+
FloorDescription
+
BuildingsExtendedBase
+
«dataType»
+
+
+
FloorRange
+
BuildingsExtendedBase
+
«dataType»
+
+
+
HeatingSourceValue
+
BuildingsExtendedBase
+
«codeList»
+
+
+
HeatingSystemValue
+
BuildingsExtendedBase
+
«codeList»
+
+
+
InstallationNatureValue
+
BuildingsExtendedBase
+
«codeList»
+
+
+
MaterialOfFacadeValue
+
BuildingsExtendedBase
+
«codeList»
+
+
+
MaterialOfRoofValue
+
BuildingsExtendedBase
+
«codeList»
+
+
+
MaterialOfStructureValue
+
BuildingsExtendedBase
+
«codeList»
+
+
+
OfficialArea
+
BuildingsExtendedBase
+
«dataType»
+
+
+
OfficialAreaReferenceValue
+
BuildingsExtendedBase
+
«codeList»
+
+
+
OfficialValue
+
BuildingsExtendedBase
+
«dataType»
+
+
+
OfficialValueReferenceValue
+
BuildingsExtendedBase
+
«codeList»
+
+
+
OtherConstructionNatureValue
+
BuildingsExtendedBase
+
«codeList»
+
+
+
OtherStandardOfficialAreaReferenceValue
+
BuildingsExtendedBase
+
«codeList»
+
+
+
RoofTypeValue
+
BuildingsExtendedBase
+
«codeList»
+
+
+
SourceStatusValue
+
BuildingsExtendedBase
+
«codeList»
+
+
+
+
+
5.6.2.1. Spatial object types
+
+
5.6.2.1.1. AbstractBuildingUnit
+
+
+
+
+
+
+
AbstractBuildingUnit (abstract)
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
Abstract building unit
+
+
+
Subtype of:
+
BuildingAndBuildingUnitInfo
+
+
+
Definition:
+
Abstract spatial object type grouping the semantic properties of building units. A BuildingUnit is a subdivision of Building with its own lockable access from the outside or from a common area (i.e. not from another BuildingUnit), which is atomic, functionally independent, and may be separately sold, rented out, inherited, etc.
+
+
+
Description:
+
Building units are spatial objects aimed at subdividing buildings and/or building parts into smaller parts that are treated as seperate entities in daily life. A building unit is homogeneous, regarding management aspects.
+EXAMPLES: It may be e.g. an apartment in a condominium, a terraced house, or a shop inside a shopping arcade.
+NOTE 1: According to national regulations, a building unit may be a flat, a cellar, a garage or set of a flat, a cellar and a garage.
+NOTE 2: According to national regulation, a building that is one entity for daily life (typically, a single family house) may be considered as a Building composed of one BuildingUnit or as a Building composed of zero BuildingUnit.
+
+
+
Stereotypes:
+
«featureType»
+
+
+
+
+
+
+
Attribute: inspireId
+
+
+
+
+
+
+
+
+
Name:
+
inspire id
+
+
+
Value type:
+
Identifier
+
+
+
Definition:
+
External object identifier of the spatial object.
+
+
+
Description:
+
An external object identifier is a unique object identifier published by the responsible body, which may be used by external applications to reference the spatial object. The identifier is an identifier of the spatial object, not an identifier of the real-world phenomenon.
+
+
+
Multiplicity:
+
1
+
+
+
+
+
+
+
Attribute: currentUse
+
+
+
+
+
+
+
+
+
Name:
+
Current use
+
+
+
Value type:
+
CurrentUseValue
+
+
+
Definition:
+
Activity hosted by the building unit.
+
+
+
Multiplicity:
+
0..*
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: externalReference
+
+
+
+
+
+
+
+
+
Name:
+
External reference
+
+
+
Value type:
+
ExternalReference
+
+
+
Definition:
+
Reference to an external information system containing any piece of information related to the spatial object.
+
+
+
Description:
+
Typically, the external reference will be established to the information system where BuildingUnits are defined.
+
+EXAMPLES: the information system will be the cadastral register or an official dwelling register. It may be also a register of public properties.
+
+
+
Multiplicity:
+
1
+
+
+
+
+
+
+
Attribute: beginLifespanVersion
+
+
+
+
+
+
+
+
+
Name:
+
Begin lifespan version
+
+
+
Value type:
+
DateTime
+
+
+
Definition:
+
Date and time at which this version of the spatial object was inserted or changed in the spatial data set.
+
+
+
Multiplicity:
+
1
+
+
+
Stereotypes:
+
«voidable,lifeCycleInfo»
+
+
+
+
+
+
+
Attribute: endLifespanVersion
+
+
+
+
+
+
+
+
+
Name:
+
End lifespan version
+
+
+
Value type:
+
DateTime
+
+
+
Definition:
+
Date and time at which this version of the spatial object was superseded or retired in the spatial data set.
+
+
+
Multiplicity:
+
0..1
+
+
+
Stereotypes:
+
«voidable,lifeCycleInfo»
+
+
+
+
+
+
+
+
+
5.6.2.1.2. AbstractInstallation
+
+
+
+
+
+
+
AbstractInstallation (abstract)
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
Abstract installation
+
+
+
Subtype of:
+
AbstractConstruction
+
+
+
Definition:
+
Abstract spatial object type grouping the semantic properties of installations. An external construction (of small size) or an external device serving the building or building part.
+
+
+
Description:
+
EXAMPLES: stairway, solar panel, external lift
+
+
+
Stereotypes:
+
«featureType»
+
+
+
+
+
+
+
Attribute: installationNature
+
+
+
+
+
+
+
+
+
Name:
+
Installation nature
+
+
+
Value type:
+
InstallationNatureValue
+
+
+
Definition:
+
A description of the installation that represents its intended nature or current function.
+
+
+
Multiplicity:
+
1
+
+
+
+
+
+
+
+
+
5.6.2.1.3. AbstractOtherConstruction
+
+
+
+
+
+
+
AbstractOtherConstruction (abstract)
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
Abstract other construction
+
+
+
Subtype of:
+
AbstractConstruction
+
+
+
Definition:
+
Abstract spatial object type grouping the semantic properties of other constructions. An other construction is a self-standing construction that belongs to theme Buildings and that is not a Building.
+
+
+
Description:
+
NOTE 1: the main difference between a building and an other construction is the fact that an other construction does not need to be enclosed.
+NOTE 2: the other constructions to be considered under scope of theme Buildings are the constructions that are not present in another INSPIRE theme and that are necessary for environmental use cases, such as the ones considered in this data specification.
+EXAMPLES: bridge, acoustic fence, city wall.
+
+
+
Stereotypes:
+
«featureType»
+
+
+
+
+
+
+
Attribute: otherConstructionNature
+
+
+
+
+
+
+
+
+
Name:
+
Other construction nature
+
+
+
Value type:
+
OtherConstructionNatureValue
+
+
+
Definition:
+
A description of the construction that represents its intended nature or current function and which differentiates it from that of a Building.
+
+
+
Multiplicity:
+
1
+
+
+
+
+
+
+
+
+
5.6.2.1.4. BuildingAndBuildingUnitInfo
+
+
+
+
+
+
+
BuildingAndBuildingUnitInfo (abstract)
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
Building and building unit info
+
+
+
Definition:
+
Abstract spatial object type grouping the additional properties that are common to Building , Building Part and BuildingUnit.
+
+
+
Description:
+
NOTE 1: The additional properties are those that are not already included in the base application schema.
+NOTE 2: These additional properties concern mainly the official information that may be attached to buildings / building parts or to building units.
+
+
+
Stereotypes:
+
«featureType»
+
+
+
+
+
+
+
Attribute: connectionToElectricity
+
+
+
+
+
+
+
+
+
Name:
+
Connection to electricity
+
+
+
Value type:
+
Boolean
+
+
+
Definition:
+
An indication if the building or building part or building unit is connected or not to the public electricity network.
+
+
+
Multiplicity:
+
0..1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: connectionToGas
+
+
+
+
+
+
+
+
+
Name:
+
Connection to gas
+
+
+
Value type:
+
Boolean
+
+
+
Definition:
+
An indication if the building or building part or building unit is connected or not to the public gas network.
+
+
+
Multiplicity:
+
0..1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: connectionToSewage
+
+
+
+
+
+
+
+
+
Name:
+
Connection to sewage
+
+
+
Value type:
+
Boolean
+
+
+
Definition:
+
An indication if the building or building part or building unit is connected or not to the public sewage network.
+
+
+
Multiplicity:
+
0..1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: connectionToWater
+
+
+
+
+
+
+
+
+
Name:
+
Connection to water
+
+
+
Value type:
+
Boolean
+
+
+
Definition:
+
An indication if the building or building part or building unit is connected or not to the public water network.
+
+
+
Multiplicity:
+
0..1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: document
+
+
+
+
+
+
+
+
+
Name:
+
Document
+
+
+
Value type:
+
Document
+
+
+
Definition:
+
Any document providing information about the building or building part or building unit.
+
+
+
Description:
+
EXAMPLES: the building permit, a photo of facade or inner yard, a sketch of interior, the building code, the energy performance assessment, an emergency plan
+
+
+
Multiplicity:
+
0..*
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: energyPerformance
+
+
+
+
+
+
+
+
+
Name:
+
Energy performance
+
+
+
Value type:
+
EnergyPerformance
+
+
+
Definition:
+
The energy performance of the building or building part or building unit .
+
+
+
Description:
+
NOTE The energy performance is required by the Energy Performance of Building Directive for the new buildings being rent or sold.
+
+
+
Multiplicity:
+
0..1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: heatingSource
+
+
+
+
+
+
+
+
+
Name:
+
Heating source
+
+
+
Value type:
+
HeatingSourceValue
+
+
+
Definition:
+
The source of energy used for the heating
+
+
+
Description:
+
EXAMPLES: electricity, natural gas
+
+
+
Multiplicity:
+
0..*
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: heatingSystem
+
+
+
+
+
+
+
+
+
Name:
+
Heating system
+
+
+
Value type:
+
HeatingSystemValue
+
+
+
Definition:
+
The system of heating
+
+
+
Description:
+
EXAMPLES : stove, central heating, heat pump
+
+
+
Multiplicity:
+
0..*
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: address
+
+
+
+
+
+
+
+
+
Name:
+
Address
+
+
+
Value type:
+
AddressRepresentation
+
+
+
Definition:
+
The address(es) of the building or building part or building unit.
+
+
+
Description:
+
This attribute provides the current address(es) of the building or building component in the structured data type defined in theme Address.
+
+
+
Multiplicity:
+
0..*
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: officialArea
+
+
+
+
+
+
+
+
+
Name:
+
Official area
+
+
+
Value type:
+
OfficialArea
+
+
+
Definition:
+
The area of the building or building part or building unit as registered in an official information system
+
+
+
Multiplicity:
+
0..*
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: officialValue
+
+
+
+
+
+
+
+
+
Name:
+
Official value
+
+
+
Value type:
+
OfficialValue
+
+
+
Definition:
+
The value of the building or building part or building unit as registered in official information system
+
+
+
Multiplicity:
+
0..*
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Association role: cadastralParcel
+
+
+
+
+
+
+
+
+
Name:
+
Cadastral parcel
+
+
+
Value type:
+
CadastralParcel
+
+
+
Definition:
+
The cadastral parcel(s) to which the building or building part or building unit is officially related.
+
+
+
Multiplicity:
+
0..*
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Association role: address
+
+
+
+
+
+
+
+
+
Name:
+
Address
+
+
+
Value type:
+
AddressRepresentation
+
+
+
Definition:
+
The address(es) of the building or building part or building unit.
+
+
+
Multiplicity:
+
0..*
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
+
+
5.6.2.1.5. BuildingInfo
+
+
+
+
+
+
+
BuildingInfo (abstract)
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
Building info
+
+
+
Subtype of:
+
BuildingAndBuildingUnitInfo
+
+
+
Definition:
+
Abstract spatial object type grouping the additional specific properties of Building and Building Part.
+
+
+
Description:
+
NOTE 1: The additonal properties are those that are not already included in the base application schema.
+NOTE 2: The specific properties are the properties that appliy to Building and BuildingPart without applying to BuildingUnit.
+
+
+
Stereotypes:
+
«featureType»
+
+
+
+
+
+
+
Attribute: heightBelowGround
+
+
+
+
+
+
+
+
+
Name:
+
Height below ground
+
+
+
Value type:
+
Length
+
+
+
Definition:
+
Height below ground of the building or building part.
+
+
+
Multiplicity:
+
0..1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: numberOfFloorsBelowGround
+
+
+
+
+
+
+
+
+
Name:
+
Number of floors below ground
+
+
+
Value type:
+
Integer
+
+
+
Definition:
+
The number of floors below ground of the building or building part.
+
+
+
Description:
+
EXAMPLES: includes cellars, underground carparks …
+
+
+
Multiplicity:
+
0..1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: floorDistribution
+
+
+
+
+
+
+
+
+
Name:
+
Floor distribution
+
+
+
Value type:
+
FloorRange
+
+
+
Definition:
+
The range(s) of floors of the building or building part.
+
+
+
Description:
+
EXAMPLE: [0,5] for a 6 floors building located on ground.
+
+
+
Multiplicity:
+
1..*
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: floorDescription
+
+
+
+
+
+
+
+
+
Name:
+
Floor description
+
+
+
Value type:
+
FloorDescription
+
+
+
Definition:
+
The description of a given range of building floors.
+
+
+
Multiplicity:
+
0..*
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: roofType
+
+
+
+
+
+
+
+
+
Name:
+
Roof type
+
+
+
Value type:
+
RoofTypeValue
+
+
+
Definition:
+
The shape of the roof.
+
+
+
Multiplicity:
+
0..*
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: materialOfFacade
+
+
+
+
+
+
+
+
+
Name:
+
Material of facade
+
+
+
Value type:
+
MaterialOfFacadeValue
+
+
+
Definition:
+
Material(s) of the building or building part facade.
+
+
+
Multiplicity:
+
0..*
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: materialOfRoof
+
+
+
+
+
+
+
+
+
Name:
+
Material of roof
+
+
+
Value type:
+
MaterialOfRoofValue
+
+
+
Definition:
+
Material(s) of the building or building part roof.
+
+
+
Multiplicity:
+
0..*
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: materialOfStructure
+
+
+
+
+
+
+
+
+
Name:
+
Material of structure
+
+
+
Value type:
+
MaterialOfStructureValue
+
+
+
Definition:
+
Material(s) of the building structure.
+
+
+
Description:
+
NOTE generally, the building structure consists of the supporting walls or columns.
+
+
+
Multiplicity:
+
0..*
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Association role: buildingUnit
+
+
+
+
+
+
+
+
+
Name:
+
Building unit
+
+
+
Value type:
+
AbstractBuildingUnit
+
+
+
Definition:
+
The building unit(s) belonging to the building or building part.
+
+
+
Multiplicity:
+
0..*
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Association role: installation
+
+
+
+
+
+
+
+
+
Value type:
+
AbstractInstallation
+
+
+
Definition:
+
The installation(s) serving the building or building part.
+
+
+
Multiplicity:
+
0..*
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
+
+
+
5.6.2.2. Data types
+
+
5.6.2.2.1. Document
+
+
+
+
+
+
+
Document
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
Document
+
+
+
Definition:
+
This data types provides the address where the document may be found and a minimum set of metadata elements considered as necessary to exploit the document.
+
+
+
Stereotypes:
+
«dataType»
+
+
+
+
+
+
+
Attribute: date
+
+
+
+
+
+
+
+
+
Name:
+
date
+
+
+
Value type:
+
DateTime
+
+
+
Definition:
+
Date of validity of the document.
+
+
+
Description:
+
EXAMPLES: the date the photo was taken, the date the sketch was done or
+approved, the date the building permit was accepted.
+
+
+
Multiplicity:
+
0..1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: documentDescription
+
+
+
+
+
+
+
+
+
Name:
+
documentDescription
+
+
+
Value type:
+
PT_FreeText
+
+
+
Definition:
+
A short text providing overview of the document content. May be just title of the document.
+
+
+
Description:
+
EXAMPLES: "photo of inner yard", "sketch of third floor"
+
+
+
Multiplicity:
+
0..1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: documentLink
+
+
+
+
+
+
+
+
+
Name:
+
documentLink
+
+
+
Value type:
+
URI
+
+
+
Definition:
+
The Universal Resource Identifier of the document.
+
+
+
Description:
+
The Internet address where the document may be found.
+
+
+
Multiplicity:
+
1
+
+
+
+
+
+
+
Attribute: sourceStatus
+
+
+
+
+
+
+
+
+
Name:
+
sourceStatus
+
+
+
Value type:
+
SourceStatusValue
+
+
+
Definition:
+
The status of the document, i.e. this attribute indicates if the document comes from official source or not.
+
+
+
Multiplicity:
+
1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
+
+
5.6.2.2.2. EnergyPerformance
+
+
+
+
+
+
+
EnergyPerformance
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
Energy performance
+
+
+
Definition:
+
This data type describes the energy performance of the building or building unit.
+
+
+
Stereotypes:
+
«dataType»
+
+
+
+
+
+
+
Attribute: energyPerformanceValue
+
+
+
+
+
+
+
+
+
Name:
+
energyPerformanceValue
+
+
+
Value type:
+
EnergyPerformanceValue
+
+
+
Definition:
+
The class of energy performance of the building or building unit.
+
+
+
Multiplicity:
+
1
+
+
+
+
+
+
+
Attribute: dateOfAssessment
+
+
+
+
+
+
+
+
+
Name:
+
dateOfAssessment
+
+
+
Value type:
+
DateTime
+
+
+
Definition:
+
The date when the energy performance of the building or building unit was assessed.
+
+
+
Multiplicity:
+
1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: assessmentMethod
+
+
+
+
+
+
+
+
+
Name:
+
assessmentMethod
+
+
+
Value type:
+
DocumentCitation
+
+
+
Definition:
+
The reference to the document describing the assessment method of energy performance.
+
+
+
Multiplicity:
+
1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
+
+
5.6.2.2.3. FloorDescription
+
+
+
+
+
+
+
FloorDescription
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
Floor description
+
+
+
Definition:
+
This data type gathers the main characteristics of a floor (or range of floors) of a building.
+
+
+
Description:
+
The common characteristics are the ones coming from the use cases considered by this data specification.
+
+
+
Stereotypes:
+
«dataType»
+
+
+
+
+
+
+
Attribute: areaOfOpenings
+
+
+
+
+
+
+
+
+
Name:
+
areaOfOpenings
+
+
+
Value type:
+
Area
+
+
+
Definition:
+
The area of openings (doors, windows, open space) on the facade of the building, related to this given floor
+
+
+
Description:
+
NOTE : the area of openings helps to assess the vulnerability of buildings to earthquakes.
+
+
+
Multiplicity:
+
1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: currentUse
+
+
+
+
+
+
+
+
+
Name:
+
currentUse
+
+
+
Value type:
+
CurrentUseValue
+
+
+
Definition:
+
The current use(s) of the floor.
+
+
+
Multiplicity:
+
1..*
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: document
+
+
+
+
+
+
+
+
+
Name:
+
document
+
+
+
Value type:
+
Document
+
+
+
Definition:
+
Any document providing information about the floor.
+
+
+
Description:
+
EXAMPLE : A sketch of the floor, emergency plan of the floor.
+
+
+
Multiplicity:
+
0..*
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: floorArea
+
+
+
+
+
+
+
+
+
Name:
+
floorArea
+
+
+
Value type:
+
Area
+
+
+
Definition:
+
The ground area of the floor.
+
+
+
Multiplicity:
+
1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: floorRange
+
+
+
+
+
+
+
+
+
Name:
+
floorRange
+
+
+
Value type:
+
FloorRange
+
+
+
Definition:
+
Therange of floors having common characteristics.
+
+
+
Description:
+
NOTEMany buildings may have ground floor with specific characteristics and upper floors looking like one another.
+
+EXAMPLE 1: Typically, the ground floor may be used for shops and the upper floors for offices or dwellings. The opening distribution is also often different on ground floor (with entrance doors, arcades, …) and in upper floors (with only windows on the facade).
+
+
+
Multiplicity:
+
1..*
+
+
+
+
+
+
+
Attribute: height
+
+
+
+
+
+
+
+
+
Name:
+
height
+
+
+
Value type:
+
Length
+
+
+
Definition:
+
The height of the floor.
+
+
+
Multiplicity:
+
1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: numberOfDwellings
+
+
+
+
+
+
+
+
+
Name:
+
numberOfDwellings
+
+
+
Value type:
+
Integer
+
+
+
Definition:
+
The number of dwellings of the floor.
+
+
+
Multiplicity:
+
1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
+
+
5.6.2.2.4. FloorRange
+
+
+
+
+
+
+
FloorRange
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
FloorRange
+
+
+
Definition:
+
The identification of a floor range by its lowest and highest floor.
+
+
+
Description:
+
NOTE 1: The ground floor should be considered as floor n°0.
+NOTE 2: If the floor range includes only one floor, the lowest and highest floor will be equal, e.g. [0,0] to identify the ground floor.
+NOTE 3: In case of a building with several building parts, the same floor should be used as reference floor, i.e. as floor n° 0.
+
+
+
Stereotypes:
+
«dataType»
+
+
+
+
+
+
+
Attribute: lowestFloor
+
+
+
+
+
+
+
+
+
Name:
+
lowestFloor
+
+
+
Value type:
+
Real
+
+
+
Definition:
+
The lowest floor in the floor range.
+
+
+
Description:
+
NOTE lowestFloor is defined as float to deal with half floors that are used by some data producers (e.g. for mezzanines). Only numbers such as .. -2, -1, 0, 1, 2, … or …, -1,5, -0.5, 0.5, 1.5, 2.5, … should be used to define lowest floor.
+
+
+
Multiplicity:
+
1
+
+
+
+
+
+
+
Attribute: highestFloor
+
+
+
+
+
+
+
+
+
Name:
+
highestFloor
+
+
+
Value type:
+
Real
+
+
+
Definition:
+
The highest floor in the floor range.
+
+
+
Description:
+
NOTE : HighestFloor is defined as float to deal with half floors that are used by some data producers (e.g. for mezzanines). Only numbers such as .. -2, -1, 0, 1, 2, … or …, -1,5, -0.5, 0.5, 1.5, 2.5, … should be used to define highest floor.
+
+
+
Multiplicity:
+
1
+
+
+
+
+
+
+
+
+
5.6.2.2.5. OfficialArea
+
+
+
+
+
+
+
OfficialArea
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
Official area
+
+
+
Definition:
+
This data types includes the official area of the building, building part or building unit and information about the exact meaning of this area.
+
+
+
Stereotypes:
+
«dataType»
+
+
+
+
+
+
+
Attribute: officialAreaReference
+
+
+
+
+
+
+
+
+
Name:
+
officialAreaReference
+
+
+
Value type:
+
OfficialAreaReferenceValue
+
+
+
Definition:
+
The type of the official area.
+
+
+
Description:
+
The type of official area may be described either by using the values provided by the CLGE measurement code for the floor area of buildings (which values are provided by the CLGE_OfficialAreaReferenceValue) or by using another standard (which values are provided by the empty code list OtherStandard OfficialAreaReferenceValue, this code list having to be defined at Member State level).
+
+
+
Multiplicity:
+
1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: value
+
+
+
+
+
+
+
+
+
Name:
+
Value
+
+
+
Value type:
+
Area
+
+
+
Definition:
+
The value of the official area
+
+
+
Multiplicity:
+
1
+
+
+
+
+
+
+
Attribute: heightParameter
+
+
+
+
+
+
+
+
+
Name:
+
heightParameter
+
+
+
Value type:
+
Length
+
+
+
Definition:
+
The height parameter used to differentiate internal primary area of internal other area, if the official area is referenced using the CLGE measurement code for the floor area of buildings
+
+
+
Description:
+
NOTE According to CLGE code, the height parameter has a default value fixed to 2.10 m but may be changed in order to fit with national regulation.
+
+
+
Multiplicity:
+
0..1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Constraint: valueUoM
+
+
+
+
+
+
+
+
+
Natural language:
+
Unit of value must be square meter.
+
+
+
OCL:
+
inv: self.value.uom.uomSymbol='m2'
+
+
+
+
+
+
+
+
+
5.6.2.2.6. OfficialValue
+
+
+
+
+
+
+
OfficialValue
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
Official value
+
+
+
Definition:
+
Data type grouping the information about the official value itself and the metadata attached to it.
+
+
+
Description:
+
The official value may be provided either directly by a value and its currency , or e.g. in case of privacy issues, by an external reference to another information system. This official value generally aims to assess the market price (valueReference) of the building (or building unit) or a given percentage of this valueReference at a valuationDate.
+
+
+
Stereotypes:
+
«dataType»
+
+
+
+
+
+
+
Attribute: currency
+
+
+
+
+
+
+
+
+
Name:
+
currency
+
+
+
Value type:
+
CurrencyValue
+
+
+
Definition:
+
The currency in which the official value is provided.
+
+
+
Multiplicity:
+
1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: value
+
+
+
+
+
+
+
+
+
Name:
+
value
+
+
+
Value type:
+
Integer
+
+
+
Definition:
+
The official value of the building or building unit.
+
+
+
Multiplicity:
+
1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: valuationDate
+
+
+
+
+
+
+
+
+
Name:
+
valuationDate
+
+
+
Value type:
+
DateTime
+
+
+
Definition:
+
The date corresponding to the assessed market price.
+
+
+
Description:
+
EXAMPLE: The official value aims to assess the market price as it was in January 2012.
+
+
+
Multiplicity:
+
1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: officialValueReference
+
+
+
+
+
+
+
+
+
Name:
+
officialValueReference
+
+
+
Value type:
+
OfficialValueReferenceValue
+
+
+
Definition:
+
The reference market price that the official value aims to assess.
+
+
+
Description:
+
EXAMPLE: rental income
+
+
+
Multiplicity:
+
1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: referencePercentage
+
+
+
+
+
+
+
+
+
Name:
+
referencePercentage
+
+
+
Value type:
+
Integer
+
+
+
Definition:
+
The percentage of the market price that the official value aims to assess.
+
+
+
Description:
+
The official value aims to assess 50% of market price.
+
+
+
Multiplicity:
+
1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: informationSystemName
+
+
+
+
+
+
+
+
+
Name:
+
informationSystemName
+
+
+
Value type:
+
PT_FreeText
+
+
+
Definition:
+
The name of an external information system where the official value may be found.
+
+
+
Description:
+
It will be possible to find the official value of the building, building part or building unit, using the external reference of the spatial object related to the given information system.
+
+
+
Multiplicity:
+
1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Constraint: either value and currency or informationSystemName shall be provided
+
+
+
+
+
+
+
+
+
Natural language:
+
Either value and currency or informationSystemName shall be provided.
+
+
+
OCL:
+
inv: (value→notEmpty() and currency→notEmpty()) or (informationSystemName→notEmpty())
+
+
+
+
+
+
+
Constraint: informationSystemName shall be present in one external reference
+
+
+
+
+
+
+
+
+
Natural language:
+
The informationSystemName shall be present in one of the external references of the spatial object.
+
+
+
OCL:
+
+
+
+
+
+
+
+
+
+
+
5.6.2.3. Code lists
+
+
5.6.2.3.1. CLGE_OfficialAreaReferenceValue
+
+
+
+
+
+
+
CLGE_OfficialAreaReferenceValue
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
CLGE_OfficialAreaReferenceValue
+
+
+
Definition:
+
List of values for the reference of official area, as defined in the CLGE measurement code for the floor area of buildings. SOURCE: http://www.eureal.eu/
The allowed values for this code list comprise the values specified in Annex C and additional values at any level defined by data providers. Annex C includes recommended values that may be used by data providers.
+
+
+
+
+
+
+
+
+
5.6.2.3.2. CurrencyValue
+
+
+
+
+
+
+
CurrencyValue
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
CurrencyValue
+
+
+
Definition:
+
Code list for possible values of attribute currency
+
+
+
Description:
+
NOTE 1: include currencies from all European countries, including that are not Member States of European Union.
+SOURCE: values are extracted from ISO 4217 standard.
+NOTE 2: this code list may be of interest not only for INSPIRE but also for other European applications and regulations ; so, in future, this code list might/should be managed outside INSPIRE.
The allowed values for this code list comprise the values specified in Annex C and additional values at any level defined by data providers. Annex C includes recommended values that may be used by data providers.
+
+
+
+
+
+
+
+
+
5.6.2.3.3. EnergyPerformanceValue
+
+
+
+
+
+
+
EnergyPerformanceValue
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
EnergyPerformanceValue
+
+
+
Definition:
+
Code list for possible values of energy performance of a building or building part or building unit.
The allowed values for this code list comprise the values specified in Annex C and additional values at any level defined by data providers. Annex C includes recommended values that may be used by data providers.
+
+
+
+
+
+
+
+
+
5.6.2.3.4. HeatingSourceValue
+
+
+
+
+
+
+
HeatingSourceValue
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
HeatingSourceValue
+
+
+
Definition:
+
Code list for the possible values of the heating source of a building, building part or building unit.
The allowed values for this code list comprise the values specified in Annex C and additional values at any level defined by data providers. Annex C includes recommended values that may be used by data providers.
+
+
+
+
+
+
+
+
+
5.6.2.3.5. HeatingSystemValue
+
+
+
+
+
+
+
HeatingSystemValue
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
HeatingSystemValue
+
+
+
Definition:
+
Code list giving the possible values for the heating system of a building, building part or building unit.
The allowed values for this code list comprise the values specified in Annex C and additional values at any level defined by data providers. Annex C includes recommended values that may be used by data providers.
+
+
+
+
+
+
+
+
+
5.6.2.3.6. InstallationNatureValue
+
+
+
+
+
+
+
InstallationNatureValue
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
InstallationNatureValue
+
+
+
Definition:
+
Code list giving the possible values of an installation nature.
The allowed values for this code list comprise the values specified in Annex C and additional values at any level defined by data providers. Annex C includes recommended values that may be used by data providers.
+
+
+
+
+
+
+
+
+
5.6.2.3.7. MaterialOfFacadeValue
+
+
+
+
+
+
+
MaterialOfFacadeValue
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
MaterialOfFacadeValue
+
+
+
Definition:
+
Code list for the possible values of MaterialOfFacade
The allowed values for this code list comprise the values specified in Annex C and additional values at any level defined by data providers. Annex C includes recommended values that may be used by data providers.
+
+
+
+
+
+
+
+
+
5.6.2.3.8. MaterialOfRoofValue
+
+
+
+
+
+
+
MaterialOfRoofValue
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
MaterialOfRoofValue
+
+
+
Definition:
+
Code list for possible values of attribute MaterialOfRoof
The allowed values for this code list comprise the values specified in Annex C and additional values at any level defined by data providers. Annex C includes recommended values that may be used by data providers.
+
+
+
+
+
+
+
+
+
5.6.2.3.9. MaterialOfStructureValue
+
+
+
+
+
+
+
MaterialOfStructureValue
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
MaterialOfStructureValue
+
+
+
Definition:
+
Code list for possible values of attribute MaterialOfStructure.
The allowed values for this code list comprise the values specified in Annex C and additional values at any level defined by data providers. Annex C includes recommended values that may be used by data providers.
+
+
+
+
+
+
+
+
+
5.6.2.3.10. OfficialAreaReferenceValue
+
+
+
+
+
+
+
OfficialAreaReferenceValue
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
OfficialAreaReferenceValue
+
+
+
Definition:
+
The list of possible values for the reference of the official area.
+
+
+
Description:
+
The type of official area may be described either by using the values provided by the CLGE measurement code for the floor area of buildings (which values are provided by the CLGE_OfficialAreaReferenceValue) or by using another standard (which values are provided by the empty code list OtherStandard OfficialAreaReferenceValue, this code list having to be defined at Member State level).
The allowed values for this code list comprise the values specified in Annex C and additional values at any level defined by data providers. Annex C includes recommended values that may be used by data providers.
+
+
+
+
+
+
+
+
+
5.6.2.3.11. OfficialValueReferenceValue
+
+
+
+
+
+
+
OfficialValueReferenceValue
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
OfficialValueReferenceValue
+
+
+
Definition:
+
The list of possible values for referencing the official value of a building, building part or building unit.
The allowed values for this code list comprise the values specified in Annex C and additional values at any level defined by data providers. Annex C includes recommended values that may be used by data providers.
Reference to a standard for official area code list.
+
+
+
Extensibility:
+
open
+
+
+
Identifier:
+
+
+
+
Values:
+
The allowed values for this code list comprise the values specified in Annex C and additional values at any level defined by data providers. Annex C includes recommended values that may be used by data providers.
+
+
+
+
+
+
+
+
+
5.6.2.3.13. RoofTypeValue
+
+
+
+
+
+
+
RoofTypeValue
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
RoofTypeValue
+
+
+
Definition:
+
Code list for the possible values of attribute roofType.
The allowed values for this code list comprise the values specified in Annex C and additional values at any level defined by data providers. Annex C includes recommended values that may be used by data providers.
+
+
+
+
+
+
+
+
+
5.6.2.3.14. SourceStatusValue
+
+
+
+
+
+
+
SourceStatusValue
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
SourceStatusValue
+
+
+
Definition:
+
Code list for possible values of attribute sourceStatus (of Document).
The allowed values for this code list comprise the values specified in Annex C and additional values at any level defined by data providers. Annex C includes recommended values that may be used by data providers.
+
+
+
+
+
+
+
+
+
5.6.2.3.15. OtherConstructionNatureValue
+
+
+
+
+
+
+
OtherConstructionNatureValue
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
OtherConstructionNatureValue
+
+
+
Definition:
+
Code list for the attribute other construction nature.
The allowed values for this code list comprise the values specified in Annex C and additional values at any level defined by data providers. Annex C includes recommended values that may be used by data providers.
+
+
+
+
+
+
+
+
+
+
5.6.2.4. Imported types (informative)
+
+
This section lists definitions for feature types, data types and code lists that are defined in other application schemas. The section is purely informative and should help the reader understand the feature catalogue presented in the previous sections. For the normative documentation of these types, see the given references.
+
+
+
5.6.2.4.1. AbstractConstruction
+
+
+
+
+
+
+
AbstractConstruction (abstract)
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
BuildingsBase
+
+
+
Reference:
+
INSPIRE Data specification on Buildings [DS-D2.8.III.2]
+
+
+
Definition:
+
Abstract spatial object type grouping the semantic properties of buildings, building parts and of some optional spatial object types that may be added in order to provide more information about the theme Buildings.
+
+
+
Description:
+
The optional spatial object types that may be added to core profiles are described in the extended profiles. The ones inheriting from the attributes of AbstractConstruction are Installation and OtherConstruction.
+
+
+
+
+
+
+
+
+
5.6.2.4.2. AddressRepresentation
+
+
+
+
+
+
+
AddressRepresentation
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
Addresses
+
+
+
Reference:
+
INSPIRE Data specification on Addresses [DS-D2.8.I.5]
+
+
+
Definition:
+
Representation of an address spatial object for use in external application schemas that need to include the basic, address information in a readable way.
+
+
+
Description:
+
NOTE 1 The data type includes the all necessary readable address components as well as the address locator(s), which allows the identification of the address spatial objects, e.g., country, region, municipality, address area, post code, street name and address number. It also includes an optional reference to the full address spatial object.
+
+NOTE 2 The datatype could be used in application schemas that wish to include address information e.g. in a dataset that registers buildings or properties.
+
+
+
+
+
+
+
+
+
5.6.2.4.3. Area
+
+
+
+
+
+
+
Area
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
Units of Measure
+
+
+
Reference:
+
Geographic information — Conceptual schema language [ISO/TS 19103:2005]
+
+
+
+
+
+
+
+
+
5.6.2.4.4. Boolean
+
+
+
+
+
+
+
Boolean
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
Truth
+
+
+
Reference:
+
Geographic information — Conceptual schema language [ISO/TS 19103:2005]
+
+
+
+
+
+
+
+
+
5.6.2.4.5. CadastralParcel
+
+
+
+
+
+
+
CadastralParcel
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
CadastralParcels
+
+
+
Reference:
+
INSPIRE Data specification on Cadastral Parcels [DS-D2.8.I.6]
+
+
+
Definition:
+
Areas defined by cadastral registers or equivalent.
+
+
+
Description:
+
SOURCE [INSPIRE Directive:2007].
+
+NOTE As much as possible, in the INSPIRE context, cadastral parcels should be forming a partition of national territory. Cadastral parcel should be considered as a single area of Earth surface (land and/or water), under homogeneous real property rights and unique ownership, real property rights and ownership being defined by national law (adapted from UN ECE 2004 and WG-CPI, 2006). By unique ownership is meant that the ownership is held by one or several joint owners for the whole parcel.
+
+
+
+
+
+
+
+
+
5.6.2.4.6. CurrentUseValue
+
+
+
+
+
+
+
CurrentUseValue
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
BuildingsBase
+
+
+
Reference:
+
INSPIRE Data specification on Buildings [DS-D2.8.III.2]
+
+
+
Definition:
+
List of possible values indicating the current use.
+
+
+
Description:
+
SOURCE: This code list is partly based on and adapted from the Eurostat classification of types of constructions (for the classification of residential buildings).
+NOTE the values of this code list apply to buildings or building components where building components may be a building part (in core profiles) or a building unit (in extended profiles)
+
+
+
+
+
+
+
+
+
5.6.2.4.7. DateTime
+
+
+
+
+
+
+
DateTime
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
Date and Time
+
+
+
Reference:
+
Geographic information — Conceptual schema language [ISO/TS 19103:2005]
+
+
+
+
+
+
+
+
+
5.6.2.4.8. DocumentCitation
+
+
+
+
+
+
+
DocumentCitation
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
Base Types 2
+
+
+
Reference:
+
INSPIRE Generic Conceptual Model, version 3.4 [DS-D2.5]
+
+
+
Definition:
+
Citation for the purposes of unambiguously referencing a document.
+
+
+
+
+
+
+
+
+
5.6.2.4.9. ExternalReference
+
+
+
+
+
+
+
ExternalReference
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
BuildingsBase
+
+
+
Reference:
+
INSPIRE Data specification on Buildings [DS-D2.8.III.2]
+
+
+
Definition:
+
Reference to an external information system containing any piece of information related to the spatial object.
+
+
+
+
+
+
+
+
+
5.6.2.4.10. Identifier
+
+
+
+
+
+
+
Identifier
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
Base Types
+
+
+
Reference:
+
INSPIRE Generic Conceptual Model, version 3.4 [DS-D2.5]
+
+
+
Definition:
+
External unique object identifier published by the responsible body, which may be used by external applications to reference the spatial object.
+
+
+
Description:
+
NOTE1 External object identifiers are distinct from thematic object identifiers.
+
+NOTE 2 The voidable version identifier attribute is not part of the unique identifier of a spatial object and may be used to distinguish two versions of the same spatial object.
+
+NOTE 3 The unique identifier will not change during the life-time of a spatial object.
+
+
+
+
+
+
+
+
+
5.6.2.4.11. Integer
+
+
+
+
+
+
+
Integer
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
Numerics
+
+
+
Reference:
+
Geographic information — Conceptual schema language [ISO/TS 19103:2005]
+
+
+
+
+
+
+
+
+
5.6.2.4.12. Length
+
+
+
+
+
+
+
Length
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
Units of Measure
+
+
+
Reference:
+
Geographic information — Conceptual schema language [ISO/TS 19103:2005]
+
+
+
+
+
+
+
+
+
5.6.2.4.13. PT_FreeText
+
+
+
+
+
+
+
PT_FreeText
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
Cultural and linguistic adapdability
+
+
+
Reference:
+
Geographic information — Metadata — XML schema implementation [ISO/TS 19139:2007]
+
+
+
+
+
+
+
+
+
5.6.2.4.14. Real
+
+
+
+
+
+
+
Real
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
Numerics
+
+
+
Reference:
+
Geographic information — Conceptual schema language [ISO/TS 19103:2005]
+
+
+
+
+
+
+
+
+
5.6.2.4.15. URI
+
+
+
+
+
+
+
URI
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
basicTypes
+
+
+
Reference:
+
Geographic information — Geography Markup Language (GML) [ISO 19136:2007]
+
+
+
+
+
+
+
+
+
+
+
+
5.7. Application schema BuildingsExtended2D
+
+
5.7.1. Description
+
+
5.7.1.1. Narrative description
+
+
<Buildings Extended 2D> application schema is an illustrative profile. It aims to be a recommendation for data providers willing to give more information than the basic one included in core 2D profile.
+
+
+
This extended profile may be used as a whole or only partly, i.e. only a selection of proposed feature types and attributes may be added. More detailed information is provided in annex F.
+
+
+
Extended2D profile is both:
+
+
+
+
+
an extension of <Buildings 2D> profile, i.e. it includes buildings and building parts with their 2D geometric representation (defined in <Base 2D>) and the basic core properties inherited from <Buildings Base>
+
+
+
an extension of <Building BaseExtended>, i.e. it includes its additional feature types (other constructions, installations and building units) and its additional properties, such as official information and more detailed physical description.
+
+
+
+
+
+
+
+
+
+
Figure 1: The <Buildings Extended2D> application schema
+
+
+
In the above figure, the feature types defined by <Buildings extended2D> are displayed in blue.
+
+
+
+
+
Feature types Building and BuildingPart inherit both from
+
+
+
+
<Buildings 2D> : buildings and building parts get the 2D geometric representation defined in this application schema and the core semantics inherited from <Buildings Base> application schema
+
+
+
<Buildings Base extended>: building and building parts get the additional properties defined in this application schema, namely the official information coming from BuildingAndBuildingUnitInfo and the more detailed topographic description coming from BuildingInfo.
+
+
+
+
+
+
+
+
The application schema <Buildings extended2D> does not define any other attribute for buildings and building parts.
+
+
+
+
+
Feature types OtherConstruction and Installation get the attribute about "nature" defined in the <Buildings Base extended> application schema and the core attributes inherited from AbstractConstruction in <Buildings Base> application schema.
+
+
+
+
+
In addition, <Buildings Extended2D> defines their 2D geometric representation as a generic GM_Object.
+
+
+
+
+
Feature types BuildingUnit inherits only the attributes defined directly in <Buildings Base Extended>, namely the specific attributes of AbstractBuildingUnit (e.g. the mandatory external reference) and the attributes common with buildings and building parts defined in BuildingAndBuildingUnitInfo.
+
+
+
+
+
In addition, <Buildings Extended2D> defines their 2D geometric representation as a generic GM_Object. Note that, in opposition to the other feature types of theme Buildings, this geometry is voidable
+
+
+
+
5.7.1.2. UML Overview
+
+
See previous Figure 53.
+
+
+
+
+
5.7.2. Feature catalogue
+
+
Feature catalogue metadata
+
+
+
+
+
+
+
+
+
Application Schema
+
INSPIRE Application Schema BuildingsExtended2D
+
+
+
Version number
+
3.0
+
+
+
+
+
Types defined in the feature catalogue
+
+
+
+
+
+
+
+
+
+
Type
+
Package
+
Stereotypes
+
+
+
+
+
Building
+
BuildingsExtended2D
+
«featureType»
+
+
+
BuildingPart
+
BuildingsExtended2D
+
«featureType»
+
+
+
BuildingUnit
+
BuildingsExtended2D
+
«featureType»
+
+
+
Installation
+
BuildingsExtended2D
+
«featureType»
+
+
+
OtherConstruction
+
BuildingsExtended2D
+
«featureType»
+
+
+
+
+
5.7.2.1. Spatial object types
+
+
5.7.2.1.1. BuildingUnit
+
+
+
+
+
+
+
BuildingUnit
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
Building unit
+
+
+
Subtype of:
+
AbstractBuildingUnit
+
+
+
Definition:
+
A BuildingUnit is a subdivision of Building with its own lockable access from the outside or from a common area (i.e. not from another BuildingUnit), which is atomic, functionally independent, and may be separately sold, rented out, inherited, etc.
+
+
+
Description:
+
Building units are spatial objects aimed at subdividing buildings and/or building parts into smaller parts that are treated as seperate entities in daily life. A building unit is homogeneous, regarding management aspects.
+EXAMPLES: It may be e.g. an apartment in a condominium, a terraced house, or a shop inside a shopping arcade.
+NOTE 1: According to national regulations, a building unit may be a flat, a cellar, a garage or set of a flat, a cellar and a garage.
+NOTE 2: According to national regulation, a building that is one entity for daily life (typically, a single family house) may be considered as a Building composed of one BuildingUnit or as a Building composed of zero BuildingUnit.
+
+
+
Stereotypes:
+
«featureType»
+
+
+
+
+
+
+
Attribute: geometry2D
+
+
+
+
+
+
+
+
+
Name:
+
Geometry 2D
+
+
+
Value type:
+
GM_Primitive
+
+
+
Definition:
+
The 2D or 2,5 D geometric representation of the building unit.
+
+
+
Description:
+
EXAMPLE: the building unit may be represented by its floor surface or by a simple point.
+
+
+
Multiplicity:
+
1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
+
+
5.7.2.1.2. Installation
+
+
+
+
+
+
+
Installation
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
Installation
+
+
+
Subtype of:
+
AbstractInstallation
+
+
+
Definition:
+
An external construction (of small size) or an external device serving the building or building part.
+
+
+
Description:
+
EXAMPLES: stairway, solar panel, external lift
+
+
+
Stereotypes:
+
«featureType»
+
+
+
+
+
+
+
Attribute: geometry2D
+
+
+
+
+
+
+
+
+
Name:
+
Geometry 2D
+
+
+
Value type:
+
GM_Primitive
+
+
+
Definition:
+
2D or 2,5 D geometric representation of the other construction.
+
+
+
Multiplicity:
+
1
+
+
+
+
+
+
+
+
+
5.7.2.1.3. OtherConstruction
+
+
+
+
+
+
+
OtherConstruction
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
Other construction
+
+
+
Subtype of:
+
AbstractOtherConstruction
+
+
+
Definition:
+
An OtherConstruction is a self-standing construction that belongs to theme Buildings and that is not a Building.
+
+
+
Description:
+
NOTE 1: the main difference between a building and an other construction is the fact that an other construction does not need to be enclosed.
+NOTE 2: the other constructions to be considered under scope of theme buildings are the constructions that are not present in another INSPIRE theme and that are necessary for environmental use cases, such as the ones considered in this data specification.
+EXAMPLES: bridge, acoustic fence, city wall.
+
+
+
Stereotypes:
+
«featureType»
+
+
+
+
+
+
+
Attribute: geometry2D
+
+
+
+
+
+
+
+
+
Name:
+
Geometry 2D
+
+
+
Value type:
+
GM_Primitive
+
+
+
Definition:
+
<font color="#0f0f0f">Geometric representation of the building.
+
+
+
Multiplicity:
+
1
+
+
+
+
+
+
+
+
+
5.7.2.1.4. Building
+
+
+
+
+
+
+
Building
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
Building
+
+
+
Subtype of:
+
BuildingInfoBuilding
+
+
+
Definition:
+
A Building is an enclosed construction above and/or underground, used or intended for the shelter of humans, animals or things or for the production of economic goods. A building refers to any structure permanently constructed or erected on its site.
+
+
+
Stereotypes:
+
«featureType»
+
+
+
+
+
+
+
+
+
5.7.2.1.5. BuildingPart
+
+
+
+
+
+
+
BuildingPart
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
Building part
+
+
+
Subtype of:
+
BuildingInfoBuildingPart
+
+
+
Definition:
+
A BuildingPart is a sub-division of a Building that might be considered itself as a building.
+
+
+
Description:
+
NOTE 1: A BuildingPart is homogeneous related to its physical, functional or temporal aspects.
+
+NOTE 2: Building and BuildingPart share the same set of properties.
+EXAMPLE: A Building may be composed of two BuildingParts having different heights above ground.
+
+
+
Stereotypes:
+
«featureType»
+
+
+
+
+
+
+
+
+
+
5.7.2.2. Imported types (informative)
+
+
This section lists definitions for feature types, data types and code lists that are defined in other application schemas. The section is purely informative and should help the reader understand the feature catalogue presented in the previous sections. For the normative documentation of these types, see the given references.
+
+
+
5.7.2.2.1. AbstractBuildingUnit
+
+
+
+
+
+
+
AbstractBuildingUnit (abstract)
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
BuildingsExtendedBase
+
+
+
Reference:
+
INSPIRE Data specification on Buildings [DS-D2.8.III.2]
+
+
+
Definition:
+
Abstract spatial object type grouping the semantic properties of building units. A BuildingUnit is a subdivision of Building with its own lockable access from the outside or from a common area (i.e. not from another BuildingUnit), which is atomic, functionally independent, and may be separately sold, rented out, inherited, etc.
+
+
+
Description:
+
Building units are spatial objects aimed at subdividing buildings and/or building parts into smaller parts that are treated as seperate entities in daily life. A building unit is homogeneous, regarding management aspects.
+EXAMPLES: It may be e.g. an apartment in a condominium, a terraced house, or a shop inside a shopping arcade.
+NOTE 1: According to national regulations, a building unit may be a flat, a cellar, a garage or set of a flat, a cellar and a garage.
+NOTE 2: According to national regulation, a building that is one entity for daily life (typically, a single family house) may be considered as a Building composed of one BuildingUnit or as a Building composed of zero BuildingUnit.
+
+
+
+
+
+
+
+
+
5.7.2.2.2. AbstractInstallation
+
+
+
+
+
+
+
AbstractInstallation (abstract)
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
BuildingsExtendedBase
+
+
+
Reference:
+
INSPIRE Data specification on Buildings [DS-D2.8.III.2]
+
+
+
Definition:
+
Abstract spatial object type grouping the semantic properties of installations. An external construction (of small size) or an external device serving the building or building part.
+
+
+
Description:
+
EXAMPLES: stairway, solar panel, external lift
+
+
+
+
+
+
+
+
+
5.7.2.2.3. AbstractOtherConstruction
+
+
+
+
+
+
+
AbstractOtherConstruction (abstract)
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
BuildingsExtendedBase
+
+
+
Reference:
+
INSPIRE Data specification on Buildings [DS-D2.8.III.2]
+
+
+
Definition:
+
Abstract spatial object type grouping the semantic properties of other constructions. An other construction is a self-standing construction that belongs to theme Buildings and that is not a Building.
+
+
+
Description:
+
NOTE 1: the main difference between a building and an other construction is the fact that an other construction does not need to be enclosed.
+NOTE 2: the other constructions to be considered under scope of theme Buildings are the constructions that are not present in another INSPIRE theme and that are necessary for environmental use cases, such as the ones considered in this data specification.
+EXAMPLES: bridge, acoustic fence, city wall.
+
+
+
+
+
+
+
+
+
5.7.2.2.4. BuildingInfo
+
+
+
+
+
+
+
BuildingInfo (abstract)
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
BuildingsExtendedBase
+
+
+
Reference:
+
INSPIRE Data specification on Buildings [DS-D2.8.III.2]
+
+
+
Definition:
+
Abstract spatial object type grouping the additional specific properties of Building and Building Part.
+
+
+
Description:
+
NOTE 1: The additonal properties are those that are not already included in the base application schema.
+NOTE 2: The specific properties are the properties that appliy to Building and BuildingPart without applying to BuildingUnit.
+
+
+
+
+
+
+
+
+
5.7.2.2.5. GM_Primitive
+
+
+
+
+
+
+
GM_Primitive (abstract)
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
Geometric primitive
+
+
+
Reference:
+
Geographic information — Spatial schema [ISO 19107:2003]
+
+
+
+
+
+
+
+
+
+
+
+
5.8. Application schema BuildingsExtended3D
+
+
5.8.1. Description
+
+
5.8.1.1. Narrative description
+
+
<Buildings Extended 3D> application schema is an illustrative profile. It aims to be a recommendation for data providers willing to give more information than the basic one included in core 3D profile.
+
+
+
This extended profile may be used as a whole or only partly, i.e. only a selection of proposed feature types and attributes may be added. More detailed information is provided in annex F.
+
+
+
<Buildings Extended3D> profile is both:
+
+
+
+
+
an extension of <Buildings 3D> application schema, i.e. it includes buildings and building parts with their 2D geometric representation (defined in <Base 3D>) and the basic core properties inherited from <Buildings Base>
+
+
+
an extension of <Building BaseExtended>, i.e. it includes its additional feature types (other constructions, installations and building units) and its additional properties, such as official information and more detailed physical description.
+
+
+
+
+
In addition, <Buildings Extended3D> offers a more detailed description of buildings and building parts by defining their physical components, such as roof, walls, ground, openings, room and by describing mechanisms to attach a texture to these components.
+
+
+
5.8.1.1.1. Main feature types
+
+
+
+
+
+
+
Figure 54: The main feature types of <Buildings Extended3D>
+
+
+
In the above figure, the feature types defined by <Buildings extended3D> are displayed in pink.
+
+
+
+
+
Feature types Building and BuildingPart inherit both from
+
+
+
+
<Buildings 3D> : buildings and building parts get the 3D geometric representation defined in this application schema and the core semantics inherited from <Buildings Base> application schema
+
+
+
<Buildings Base extended>: building and building parts get the additional properties defined in this application schema, namely the official information coming from BuildingAndBuildingUnitInfo and the more detailed topographic description coming from BuildingInfo.
+
+
+
+
+
+
+
+
The application schema <Buildings extended3D> does not define any other attribute for buildings and building parts.
+
+
+
+
+
Feature types OtherConstruction and Installation get the attribute about "nature" defined in the <Buildings Base extended> application schema and the core attributes inherited from AbstractConstruction in <Buildings Base> application schema.
+
+
+
+
+
In addition, <Buildings Extended2D> defines their 3D geometric representation as a generic GM_Object (that shall obviously be given with 3D coordinates).
+
+
+
+
+
Feature types BuildingUnit inherits only the attributes defined directly in <Buildings Base Extended>, namely the specific attributes of AbstractBuildingUnit (e.g. the mandatory external reference) and the attributes common with buildings and building parts defined in BuildingAndBuildingUnitInfo.
+
+
+
+
+
In addition, <Buildings Extended3D> defines their 3D geometric representation as a GM_MultiSolid.
+
+
+
+
5.8.1.1.2. The 3D building model
+
+
As in <Buildings 2D>, the buildings and building parts may be represented by a solid or a multi-surface, according to the various LoDs of City GML.
+
+
+
Moreover, the components of the building may also be semantically described by specific feature types:
+
+
+
+
+
in LoD2 : boundary surfaces(e.g. walls and roof ) and installations
+
+
+
in LoD3 : openings (doors and windows) are added
+
+
+
in Lod4: the interior of building (building units, rooms, internal installations) are added.
+
+
+
+
+
+
+
+
+
+
Figure 55: Modeling of LoD2, LoD3 and LoD4
+
+
+
In the Figure 55, the main feature types (Building, BuildingPart, BuildingUnit,Installation, OtherConstruction) are represented in pink, without their attributes. These attributes have been described in previous paragraph and figure. The new feature types are represented in orange.
+
+
+
+
+
+
+
+
Figure 56: Examples of use of OuterFloorSurface and OuterCeilingSurface
+
+
+
LoD 4 relates to description of building interior. In CityGML, it is limited to the representation of Rooms and InteriorInstallations; in INSPIRE model, the representation of BuildingUnits has been added.
+
+
+
Feature types BuildingUnit and Room may be represented separately or together; in last case, the BuildingUnit will be composed of Rooms.
+
+
+
+
5.8.1.1.3. Geometry of 3D feature types
+
+
The geometry of 3D feature types has to be provided using one of these 5 types:
+
+
+
+
+
BuildingGeometry3D: it is the data type defined in core 3D profile. It is used to represent the 2 core feature types : buildings and building parts.
+
+
+
GM_Solid or GM_MultiSolid: it is the simple geometry primitive to represent the volumetric features related to of the building interior, i.e. rooms and building units. Note that these feature types have to be represented only in LoD4. The GM_Solid has to be used for rooms and the GM_MultiSolid for the building units.
+
+
+
BoundaryGeometry3D : this data type has to be used to represent the objects that are surfaces, i.e. wall surfaces, roof surfaces, closure surfaces, ground surfaces, outer ceiling surfaces, outer floor surface and openings (doors and windows). The boundary surface may be represented at different levels of detail, namely LoD2, LoD3 and LoD4. It is recommended to provide the accuracy of this geometric representation, both in its horizontal and vertical dimensions (see figure below).
+
+
+
GM_Object: this generic geometric primitive has to be used to represent the objects whose shape may be a volume, a surface or a line. This data type is used for internal and external installations and for other constructions. For instance:
+
+
+
An antenna may be represented by a vertical line
+
+
+
Solar panel may be represented by a surface
+
+
+
Dormer may be represented by a volume / solid.
+
+
+
+
+
NOTE In <Buildings Extended 3D> spatial objects may be solid, surfaces, lines or even points but their geometry has to be given with 3 coordinates.
+
+
+
+
+
+
+
+
Figure 57: The data type BoundaryGeometry3D
+
+
+
+
5.8.1.1.4. The appearance model
+
+
The INSIRE appearance model is based on City GML one. See more details about how a texture may be attached to the main features of the building model in annex D.
+
+
+
+
+
+
+
+
Figure 58: The appearance part (simplification of CityGML appearance model)
+
+
+
+
+
5.8.1.2. UML Overview
+
+
See previous figures.
+
+
+
+
5.8.1.3. Identifier management
+
+
NOTE For the detailed feature types of <Buildings Extended3D> application schema (such as roofs, walls, openings, rooms), the attribute inspireId is voidable whereas it is mandatory for the main feature types (buildings, buildings parts, installations, building units, other constructions).
+
+
+
+
5.8.1.4. Geometry representation
+
+
Art. 12(1) of Regulation 1089/2010 restricts the value domain of spatial properties to the Simple Feature spatial schema as defined in the OpenGIS® Implementation Standard for Geographic information – Simple feature access – Part 1: Common architecture, version 1.2.1, unless specified otherwise for a specific spatial data theme or type.
+
+
+
+
+
+
📒
+
+
+
+
TG Requirement
+
+
+
By way of derogation from article 12(1), the value domain of spatial properties used in the Buildings 3D package shall not be restricted to simple feature.
+
+
+
+
+
+
+
+
+
5.8.2. Feature catalogue
+
+
Feature catalogue metadata
+
+
+
+
+
+
+
+
+
Application Schema
+
INSPIRE Application Schema BuildingsExtended3D
+
+
+
Version number
+
3.0
+
+
+
+
+
Types defined in the feature catalogue
+
+
+
+
+
+
+
+
+
+
Type
+
Package
+
Stereotypes
+
+
+
+
+
BoundaryGeometry3D
+
BuildingsExtended3D
+
«dataType»
+
+
+
BoundarySurface
+
BuildingsExtended3D
+
«featureType»
+
+
+
Building
+
BuildingsExtended3D
+
«featureType»
+
+
+
BuildingPart
+
BuildingsExtended3D
+
«featureType»
+
+
+
BuildingUnit
+
BuildingsExtended3D
+
«featureType»
+
+
+
ClosureSurface
+
BuildingsExtended3D
+
«featureType»
+
+
+
Door
+
BuildingsExtended3D
+
«featureType»
+
+
+
GroundSurface
+
BuildingsExtended3D
+
«featureType»
+
+
+
Installation
+
BuildingsExtended3D
+
«featureType»
+
+
+
InteriorInstallation
+
BuildingsExtended3D
+
«featureType»
+
+
+
InternalInstallationNatureValue
+
BuildingsExtended3D
+
«codeList»
+
+
+
MimeTypeValue
+
BuildingsExtended3D
+
«codeList»
+
+
+
Opening
+
BuildingsExtended3D
+
«featureType»
+
+
+
OtherConstruction
+
BuildingsExtended3D
+
«featureType»
+
+
+
OuterCeilingSurface
+
BuildingsExtended3D
+
«featureType»
+
+
+
OuterFloorSurface
+
BuildingsExtended3D
+
«featureType»
+
+
+
ParameterizedTexture
+
BuildingsExtended3D
+
«featureType»
+
+
+
RoofSurface
+
BuildingsExtended3D
+
«featureType»
+
+
+
Room
+
BuildingsExtended3D
+
«featureType»
+
+
+
RoomNatureValue
+
BuildingsExtended3D
+
«codeList»
+
+
+
TextCoordGen
+
BuildingsExtended3D
+
«dataType»
+
+
+
TextCoordList
+
BuildingsExtended3D
+
«dataType»
+
+
+
TextureParametrization
+
BuildingsExtended3D
+
«dataType»
+
+
+
TextureTypeValue
+
BuildingsExtended3D
+
«codeList»
+
+
+
TransformationMatrix3x4
+
BuildingsExtended3D
+
«dataType»
+
+
+
WallSurface
+
BuildingsExtended3D
+
«featureType»
+
+
+
Window
+
BuildingsExtended3D
+
«featureType»
+
+
+
+
+
5.8.2.1. Spatial object types
+
+
5.8.2.1.1. BoundarySurface
+
+
+
+
+
+
+
BoundarySurface
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
BoundarySurface
+
+
+
Definition:
+
Spatial objects being part of the building exterior shell with a special function.
+
+
+
Description:
+
EXAMPLES: wall (WallSurface), roof (RoofSurface), ground plate (GroundSurface) or ClosureSurface.
+
+
+
Stereotypes:
+
«featureType»
+
+
+
+
+
+
+
Attribute: inspireId
+
+
+
+
+
+
+
+
+
Name:
+
inspireId
+
+
+
Value type:
+
Identifier
+
+
+
Definition:
+
External unique object identifier published by the responsible body, which may be used by external applications to reference the spatial object.
+
+
+
Description:
+
NOTE1 External object identifiers are distinct from thematic object identifiers.
+NOTE 2 The voidable version identifier attribute is not part of the unique identifier of a spatial object and may be used to distinguish two versions of the same spatial object.
+NOTE 3 The unique identifier will not change during the life-time of a spatial object.
+
+
+
Multiplicity:
+
1
+
+
+
+
+
+
+
Attribute: geometry3D
+
+
+
+
+
+
+
+
+
Name:
+
geometry3D
+
+
+
Value type:
+
BoundaryGeometry3D
+
+
+
Definition:
+
The 3D geometric represenation of the boundary (surface embedded in 3D).
+
+
+
Multiplicity:
+
1
+
+
+
+
+
+
+
Attribute: beginLifespanVersion
+
+
+
+
+
+
+
+
+
Name:
+
beginLifespanVersion
+
+
+
Value type:
+
DateTime
+
+
+
Definition:
+
Date and time at which this version of the spatial object was inserted or changed in the spatial data set.
+
+
+
Multiplicity:
+
1
+
+
+
Stereotypes:
+
«voidable,lifeCycleInfo»
+
+
+
+
+
+
+
Attribute: endLifespanVersion
+
+
+
+
+
+
+
+
+
Name:
+
endLifespanVersion
+
+
+
Value type:
+
DateTime
+
+
+
Definition:
+
Date and time at which this version of the spatial object was superseded or retired in the spatial data set.
+
+
+
Multiplicity:
+
0..1
+
+
+
Stereotypes:
+
«voidable,lifeCycleInfo»
+
+
+
+
+
+
+
Association role: opening
+
+
+
+
+
+
+
+
+
Value type:
+
Opening
+
+
+
Definition:
+
The opening(s) being part of the boundary surface.
+
+
+
Multiplicity:
+
0..*
+
+
+
+
+
+
+
+
+
5.8.2.1.2. Building
+
+
+
+
+
+
+
Building
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
Building
+
+
+
Subtype of:
+
BuildingInfoBuilding
+
+
+
Definition:
+
A Building is an enclosed construction above and/or underground, used or intended for the shelter of humans, animals or things or for the production of economic goods. A building refers to any structure permanently constructed or erected on its site.
+
+
+
Stereotypes:
+
«featureType»
+
+
+
+
+
+
+
Association role: interiorInstallation
+
+
+
+
+
+
+
+
+
Value type:
+
InteriorInstallation
+
+
+
Definition:
+
The interior installation(s) serving the building.
+
+
+
Multiplicity:
+
0..*
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Association role: boundedBy
+
+
+
+
+
+
+
+
+
Value type:
+
BoundarySurface
+
+
+
Definition:
+
The surface(s) bounding the building.
+
+
+
Multiplicity:
+
0..*
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Association role: appearance
+
+
+
+
+
+
+
+
+
Value type:
+
ParameterizedTexture
+
+
+
Definition:
+
The texture(s) attached to the building and giving it its appearance.
+
+
+
Multiplicity:
+
0..*
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Association role: room
+
+
+
+
+
+
+
+
+
Value type:
+
Room
+
+
+
Definition:
+
The room(s) composing the building.
+
+
+
Multiplicity:
+
0..*
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Constraint: Building units shall be 3D
+
+
+
+
+
+
+
+
+
Natural language:
+
The building units associated with the building shall be represented using the BuildingUnit type of the Buildings extended 3D package.
A BuildingPart is a sub-division of a Building that might be considered itself as a building.
+
+
+
Description:
+
NOTE 1: A BuildingPart is homogeneous related to its physical, functional or temporal aspects
+NOTE2: Building and BuildingPart share the same set of properties.
+
+EXAMPLE: A building may be composed of two building parts having different heights above ground.
+
+
+
Stereotypes:
+
«featureType»
+
+
+
+
+
+
+
Association role: interiorInstallation
+
+
+
+
+
+
+
+
+
Value type:
+
InteriorInstallation
+
+
+
Definition:
+
The interior installation(s) serving the building part.
+
+
+
Multiplicity:
+
0..*
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Association role: appearance
+
+
+
+
+
+
+
+
+
Value type:
+
ParameterizedTexture
+
+
+
Definition:
+
The texture(s) attached to the building part and giving it its appearance.
+
+
+
Multiplicity:
+
0..*
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Association role: boundedBy
+
+
+
+
+
+
+
+
+
Value type:
+
BoundarySurface
+
+
+
Definition:
+
The surface(s) bounding the building part.
+
+
+
Multiplicity:
+
0..*
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Association role: room
+
+
+
+
+
+
+
+
+
Value type:
+
Room
+
+
+
Definition:
+
The room(s) composing the building part.
+
+
+
Multiplicity:
+
0..*
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Constraint: Building units shall be 3D
+
+
+
+
+
+
+
+
+
Natural language:
+
The building units associated with the building shall be represented using the BuildingUnit type of the Buildings3D extended package.
A BuildingPart must provide at least one geometry3D.
+
+
+
+
+
+
+
+
+
5.8.2.1.4. BuildingUnit
+
+
+
+
+
+
+
BuildingUnit
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
Building unit
+
+
+
Subtype of:
+
AbstractBuildingUnit
+
+
+
Definition:
+
A BuildingUnit is a subdivision of Building with its own lockable access from the outside or from a common area (i.e. not from another BuildingUnit), which is atomic, functionally independent, and may be separately sold, rented out, inherited, etc.
+
+
+
Description:
+
Building units are spatial objects aimed at subdividing buildings and/or building parts into smaller parts that are treated as seperate entities in daily life. A building unit is homogeneous, regarding management aspects.
+EXAMPLES: It may be e.g. an apartment in a condominium, a terraced house, or a shop inside a shopping arcade.
+NOTE 1: According to national regulations, a building unit may be a flat, a cellar, a garage or set of a flat, a cellar and a garage.
+NOTE 2: According to national regulation, a building that is one entity for daily life (typically, a single family house) may be considered as a Building composed of one BuildingUnit or as a Building composed of zero BuildingUnit.
+
+
+
Stereotypes:
+
«featureType»
+
+
+
+
+
+
+
Attribute: geometry2D
+
+
+
+
+
+
+
+
+
Name:
+
Geometry 2D
+
+
+
Value type:
+
GM_Primitive
+
+
+
Definition:
+
2D or 2.5D geometric representation.
+
+
+
Multiplicity:
+
0..*
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: geometry3D
+
+
+
+
+
+
+
+
+
Name:
+
Geometry 3D
+
+
+
Value type:
+
GM_MultiSolid
+
+
+
Definition:
+
3D geometric representation.
+
+
+
Multiplicity:
+
1
+
+
+
+
+
+
+
Association role: room
+
+
+
+
+
+
+
+
+
Value type:
+
Room
+
+
+
Definition:
+
The room(s) composing the building unit.
+
+
+
Multiplicity:
+
0..*
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
+
+
5.8.2.1.5. ClosureSurface
+
+
+
+
+
+
+
ClosureSurface
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
ClosureSurface
+
+
+
Subtype of:
+
BoundarySurface
+
+
+
Definition:
+
ClosureSurfaces are used for buildings which are not enclosed completely, for example airplane hangars or barns. In order to represent those objects as geometrically closed volume object, the open sides are sealed (virtually closed) by ClosureSurfaces.
+
+
+
Description:
+
NOTE Those special surfaces are taken into account, when needed to compute volumes and are neglected, when they are irrelevant or not appropriate, for example in visualisations.
+
+
+
Stereotypes:
+
«featureType»
+
+
+
+
+
+
+
+
+
5.8.2.1.6. Door
+
+
+
+
+
+
+
Door
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
Door
+
+
+
Subtype of:
+
Opening
+
+
+
Definition:
+
The doors in the exterior shell of a building or between adjacent rooms. Doors can be used by people to enter or leave a building or room.
+
+
+
Description:
+
NOTE When using LoD2 or LoD3 of CityGML (as indicated in INSPIRE Extended3D profile), the feature type Door is limited to the doors in the exterior shell of the building.
+Source: adapted from City GML.
+
+
+
Stereotypes:
+
«featureType»
+
+
+
+
+
+
+
+
+
5.8.2.1.7. GroundSurface
+
+
+
+
+
+
+
GroundSurface
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
GroundSurface
+
+
+
Subtype of:
+
BoundarySurface
+
+
+
Definition:
+
A spatial object representing the ground plate of a building or building part. The polygon defining the ground plate is congruent with the building footprint.
+
+
+
Description:
+
Source: adapted from City GML
+
+
+
Stereotypes:
+
«featureType»
+
+
+
+
+
+
+
+
+
5.8.2.1.8. Installation
+
+
+
+
+
+
+
Installation
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
Installation
+
+
+
Subtype of:
+
AbstractInstallation
+
+
+
Definition:
+
An external construction (of small size) or an external device serving the building or building part.
+
+
+
Description:
+
EXAMPLES: stairway, solar panel, external lift
+
+
+
Stereotypes:
+
«featureType»
+
+
+
+
+
+
+
Attribute: geometry2D
+
+
+
+
+
+
+
+
+
Name:
+
Geometry 2D
+
+
+
Value type:
+
GM_Primitive
+
+
+
Definition:
+
2D or 2.5D geometric representation.
+
+
+
Multiplicity:
+
0..*
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: geometry3D
+
+
+
+
+
+
+
+
+
Name:
+
Geometry 3D
+
+
+
Value type:
+
GM_Object
+
+
+
Definition:
+
3D geometric representation.
+
+
+
Multiplicity:
+
1
+
+
+
+
+
+
+
Association role: appearance
+
+
+
+
+
+
+
+
+
Value type:
+
ParameterizedTexture
+
+
+
Definition:
+
The texture(s) attached to the installation and giving it its appearance.
+
+
+
Multiplicity:
+
0..*
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Association role: boundedBy
+
+
+
+
+
+
+
+
+
Value type:
+
BoundarySurface
+
+
+
Definition:
+
The surface(s) bounding the installation.
+
+
+
Multiplicity:
+
0..*
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
+
+
5.8.2.1.9. InteriorInstallation
+
+
+
+
+
+
+
InteriorInstallation
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
InteriorInstallation
+
+
+
Definition:
+
An internal construction (generally of small size) or an internal device, serving the building or building part
+
+
+
Description:
+
EXAMPLE: stairs, lift
+
+
+
Stereotypes:
+
«featureType»
+
+
+
+
+
+
+
Attribute: inspireId
+
+
+
+
+
+
+
+
+
Name:
+
inspireId
+
+
+
Value type:
+
Identifier
+
+
+
Definition:
+
External unique object identifier published by the responsible body, which may be used by external applications to reference the spatial object.
+
+
+
Description:
+
NOTE1 External object identifiers are distinct from thematic object identifiers.
+NOTE 2 The voidable version identifier attribute is not part of the unique identifier of a spatial object and may be used to distinguish two versions of the same spatial object.
+NOTE 3 The unique identifier will not change during the life-time of a spatial object.
+
+
+
Multiplicity:
+
0..1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: geometry3D
+
+
+
+
+
+
+
+
+
Name:
+
geometry3D
+
+
+
Value type:
+
GM_Object
+
+
+
Definition:
+
3D geometric representation of the internal installation.
+
+
+
Multiplicity:
+
1
+
+
+
+
+
+
+
Attribute: installationNature
+
+
+
+
+
+
+
+
+
Name:
+
installationNature
+
+
+
Value type:
+
InternalInstallationNatureValue
+
+
+
Definition:
+
The nature of the internal installation.
+
+
+
Multiplicity:
+
1
+
+
+
+
+
+
+
Attribute: beginLifespanVersion
+
+
+
+
+
+
+
+
+
Name:
+
beginLifespanVersion
+
+
+
Value type:
+
DateTime
+
+
+
Definition:
+
Date and time at which this version of the spatial object was inserted or changed in the spatial data set.
+
+
+
Multiplicity:
+
1
+
+
+
Stereotypes:
+
«voidable,lifeCycleInfo»
+
+
+
+
+
+
+
Attribute: endLifespanVersion
+
+
+
+
+
+
+
+
+
Name:
+
endLifespanVersion
+
+
+
Value type:
+
DateTime
+
+
+
Definition:
+
Date and time at which this version of the spatial object was superseded or retired in the spatial data set.
+
+
+
Multiplicity:
+
0..1
+
+
+
Stereotypes:
+
«voidable,lifeCycleInfo»
+
+
+
+
+
+
+
+
+
5.8.2.1.10. Opening
+
+
+
+
+
+
+
Opening
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
Opening
+
+
+
Definition:
+
The feature type Opening is the (abstract) base class for semantically describing openings like doors or windows in outer or inner walls. Openings only exist in models of LoD3 or LoD4.
+
+
+
Description:
+
NOTE when using LoD3 of CityGML (as indicated in this INSPIRE Extended3D application schema), the spatial object type Opening is limited to the openings in the outer walls of the building
+Source : adapted from CityGML
+
+
+
Stereotypes:
+
«featureType»
+
+
+
+
+
+
+
Attribute: inspireId
+
+
+
+
+
+
+
+
+
Name:
+
inspireId
+
+
+
Value type:
+
Identifier
+
+
+
Definition:
+
External unique object identifier published by the responsible body, which may be used by external applications to reference the spatial object.
+
+
+
Description:
+
NOTE1 External object identifiers are distinct from thematic object identifiers.
+NOTE 2 The voidable version identifier attribute is not part of the unique identifier of a spatial object and may be used to distinguish two versions of the same spatial object.
+NOTE 3 The unique identifier will not change during the life-time of a spatial object.
+
+
+
Multiplicity:
+
1
+
+
+
+
+
+
+
Attribute: geometry3D
+
+
+
+
+
+
+
+
+
Name:
+
geometry3D
+
+
+
Value type:
+
BoundaryGeometry3D
+
+
+
Definition:
+
3D geometric representation of the opening (surface embedded in 3D).
+
+
+
Multiplicity:
+
1
+
+
+
+
+
+
+
Attribute: beginLifespanVersion
+
+
+
+
+
+
+
+
+
Name:
+
beginLifespanVersion
+
+
+
Value type:
+
DateTime
+
+
+
Definition:
+
Date and time at which this version of the spatial object was inserted or changed in the spatial data set.
+
+
+
Multiplicity:
+
1
+
+
+
Stereotypes:
+
«voidable,lifeCycleInfo»
+
+
+
+
+
+
+
Attribute: endLifespanVersion
+
+
+
+
+
+
+
+
+
Name:
+
endLifespanVersion
+
+
+
Value type:
+
DateTime
+
+
+
Definition:
+
Date and time at which this version of the spatial object was superseded or retired in the spatial data set.
+
+
+
Multiplicity:
+
0..1
+
+
+
Stereotypes:
+
«voidable,lifeCycleInfo»
+
+
+
+
+
+
+
+
+
5.8.2.1.11. OtherConstruction
+
+
+
+
+
+
+
OtherConstruction
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
Other construction
+
+
+
Subtype of:
+
AbstractOtherConstruction
+
+
+
Definition:
+
An OtherConstruction is a self-standing construction that belongs to theme Buildings and that is not a Building.
+
+
+
Description:
+
NOTE 1: the main difference between a building and an other construction is the fact that an other construction does not need to be enclosed.
+NOTE 2: the other constructions to be considered under scope of theme buildings are the constructions that are not present in another INSPIRE theme and that are necessary for environmental use cases, such as the ones considered in this data specification.
+EXAMPLES: bridge, acoustic fence, city wall.
+
+
+
Stereotypes:
+
«featureType»
+
+
+
+
+
+
+
Attribute: geometry2D
+
+
+
+
+
+
+
+
+
Name:
+
Geometry 2D
+
+
+
Value type:
+
GM_Primitive
+
+
+
Definition:
+
2D or 2.5D geometric representation.
+
+
+
Multiplicity:
+
0..*
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: geometry3D
+
+
+
+
+
+
+
+
+
Name:
+
Geometry 3D
+
+
+
Value type:
+
GM_Object
+
+
+
Definition:
+
3D geometric representation.
+
+
+
Multiplicity:
+
1
+
+
+
+
+
+
+
Association role: appearance
+
+
+
+
+
+
+
+
+
Value type:
+
ParameterizedTexture
+
+
+
Definition:
+
The texture(s) attached to the other construction and giving it its appearance.
+
+
+
Multiplicity:
+
0..*
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Association role: boundedBy
+
+
+
+
+
+
+
+
+
Value type:
+
BoundarySurface
+
+
+
Definition:
+
The surface(s) bounding the other construction.
+
+
+
Multiplicity:
+
0..*
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
+
+
5.8.2.1.12. OuterCeilingSurface
+
+
+
+
+
+
+
OuterCeilingSurface
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
OuterCeilingSurface
+
+
+
Subtype of:
+
BoundarySurface
+
+
+
Definition:
+
A surface (feature) belonging to the outer building shell and having the orientation pointing downwards.
+
+
+
Description:
+
EXAMPLES: Visible part of the ceiling of a loggia or of the ceiling of a passage.
+
+
+
Stereotypes:
+
«featureType»
+
+
+
+
+
+
+
+
+
5.8.2.1.13. OuterFloorSurface
+
+
+
+
+
+
+
OuterFloorSurface
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
OuterFloorSurface
+
+
+
Subtype of:
+
BoundarySurface
+
+
+
Definition:
+
A surface (feature) belonging to the outer building shell and with the orientation pointing upwards.
+
+
+
Description:
+
EXAMPLES: Visible part of the floor of a passage or of the floor of a loggia.
+
+
+
Stereotypes:
+
«featureType»
+
+
+
+
+
+
+
+
+
5.8.2.1.14. ParameterizedTexture
+
+
+
+
+
+
+
ParameterizedTexture
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
ParameterizedTexture
+
+
+
Definition:
+
Texture representing the appearance aspect of a surface in the exterior shell of the building. The feature type ParameterizedTexture describes texture that is mapped to a surface (target).
+
+
+
Description:
+
SOURCE: adapted from CityGML.
+
+
+
Stereotypes:
+
«featureType»
+
+
+
+
+
+
+
Attribute: imageURI
+
+
+
+
+
+
+
+
+
Name:
+
imageURI
+
+
+
Value type:
+
URI
+
+
+
Definition:
+
Uniform Resource Identifier; gives indication where the image used for the texture may be found.
+
+
+
Multiplicity:
+
1
+
+
+
+
+
+
+
Attribute: mimeType
+
+
+
+
+
+
+
+
+
Name:
+
mimeType
+
+
+
Value type:
+
MimeTypeValue
+
+
+
Definition:
+
Format of the image used for texture.
+
+
+
Multiplicity:
+
1
+
+
+
+
+
+
+
Attribute: textureType
+
+
+
+
+
+
+
+
+
Name:
+
textureType
+
+
+
Value type:
+
TextureTypeValue
+
+
+
Definition:
+
Type of the texture; gives indication if the texture comes from real-world images or from standards images in libraries.
+
+
+
Multiplicity:
+
1
+
+
+
+
+
+
+
+
+
5.8.2.1.15. RoofSurface
+
+
+
+
+
+
+
RoofSurface
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
RoofSurface
+
+
+
Subtype of:
+
BoundarySurface
+
+
+
Definition:
+
The surfaces delimiting major roof parts of a building or building part are expressed by the feature type RoofSurface.
+
+
+
Description:
+
Source: adapted from CityGML
+
+
+
Stereotypes:
+
«featureType»
+
+
+
+
+
+
+
Attribute: materialOfRoof
+
+
+
+
+
+
+
+
+
Name:
+
materialOfRoof
+
+
+
Value type:
+
MaterialOfRoofValue
+
+
+
Definition:
+
Material(s) of the building roof.
+
+
+
Multiplicity:
+
0..*
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
+
+
5.8.2.1.16. Room
+
+
+
+
+
+
+
Room
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
Room
+
+
+
Definition:
+
A room is any distinguishable space within a structure. Usually, a room is separated from other spaces by interior walls; moreover, it is separated from outdoor areas by an exterior wall, sometimes with a door.
+
+
+
Stereotypes:
+
«featureType»
+
+
+
+
+
+
+
Attribute: inspireId
+
+
+
+
+
+
+
+
+
Name:
+
inspireId
+
+
+
Value type:
+
Identifier
+
+
+
Definition:
+
External unique object identifier published by the responsible body, which may be used by external applications to reference the spatial object.
+
+
+
Description:
+
NOTE1 External object identifiers are distinct from thematic object identifiers.
+NOTE 2 The voidable version identifier attribute is not part of the unique identifier of a spatial object and may be used to distinguish two versions of the same spatial object.
+NOTE 3 The unique identifier will not change during the life-time of a spatial object.
+
+
+
Multiplicity:
+
0..1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: geometry3D
+
+
+
+
+
+
+
+
+
Name:
+
geometry3D
+
+
+
Value type:
+
GM_Solid
+
+
+
Definition:
+
3D geometric representation of the room.
+
+
+
Multiplicity:
+
1
+
+
+
+
+
+
+
Attribute: roomNature
+
+
+
+
+
+
+
+
+
Name:
+
roomNature
+
+
+
Value type:
+
RoomNatureValue
+
+
+
Definition:
+
The nature (intended use or function) of the room.
+
+
+
Multiplicity:
+
0..1
+
+
+
+
+
+
+
Attribute: beginLifespanVersion
+
+
+
+
+
+
+
+
+
Name:
+
beginLifespanVersion
+
+
+
Value type:
+
DateTime
+
+
+
Definition:
+
Date and time at which this version of the spatial object was inserted or changed in the spatial data set.
+
+
+
Multiplicity:
+
1
+
+
+
Stereotypes:
+
«voidable,lifeCycleInfo»
+
+
+
+
+
+
+
Attribute: endLifespanVersion
+
+
+
+
+
+
+
+
+
Name:
+
endLifespanVersion
+
+
+
Value type:
+
DateTime
+
+
+
Definition:
+
Date and time at which this version of the spatial object was superseded or retired in the spatial data set.
+
+
+
Multiplicity:
+
0..1
+
+
+
Stereotypes:
+
«voidable,lifeCycleInfo»
+
+
+
+
+
+
+
+
+
5.8.2.1.17. WallSurface
+
+
+
+
+
+
+
WallSurface
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
WallSurface
+
+
+
Subtype of:
+
BoundarySurface
+
+
+
Definition:
+
The surfaces that are parts of the building facade visible from the outside.
+
+
+
Description:
+
Source: adapted from CityGML.
+
+
+
Stereotypes:
+
«featureType»
+
+
+
+
+
+
+
Attribute: materialOfWall
+
+
+
+
+
+
+
+
+
Name:
+
materialOfWall
+
+
+
Value type:
+
MaterialOfFacadeValue
+
+
+
Definition:
+
Material(s) of the building exterior walls.
+
+
+
Multiplicity:
+
0..1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
+
+
5.8.2.1.18. Window
+
+
+
+
+
+
+
Window
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
Window
+
+
+
Subtype of:
+
Opening
+
+
+
Definition:
+
Windows in the exterior shell of a building, or hatches between adjacent rooms.
+
+
+
Description:
+
NOTE 1: The formal difference between the classes window and door is that in normal cases windows are not specifically intended for the transit of people or vehicles.
+NOTE 2: when using LoD3 of CityGML (as indicated in INSPIRE Extended3D aplication schema), the feature type Window is limited to the windows in the exterior shell of the building.
+Source : adapted from CityGML.
+
+
+
Stereotypes:
+
«featureType»
+
+
+
+
+
+
+
+
+
+
5.8.2.2. Data types
+
+
5.8.2.2.1. BoundaryGeometry3D
+
+
+
+
+
+
+
BoundaryGeometry3D
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
BoundaryGeometry3D
+
+
+
Definition:
+
The information related to the boundary geometry as 3D data.
The estimated absolute positional accuracy of the (X,Y) coordinates of the LoD2 boundary representation, in the INSPIRE official Coordinate Reference System. Absolute positional accuracy is defined as the mean value of the positional uncertainties for a set of positions where the positional uncertainties are defined as the distance between a measured position and what is considered as the corresponding true position.
+
+
+
Description:
+
NOTE this mean value may come from quality measures on a homogeneous population of buildings or from an estimation based on the knowledge of the production processes and of their accuracy.
The estimated absolute positional accuracy of the (X,Y) coordinates of the LoD3 boundary representation, in the INSPIRE official Coordinate Reference System. Absolute positional accuracy is defined as the mean value of the positional uncertainties for a set of positions where the positional uncertainties are defined as the distance between a measured position and what is considered as the corresponding true position.
+
+
+
Description:
+
NOTE this mean value may come from quality measures on a homogeneous population of buildings or from an estimation based on the knowledge of the production processes and of their accuracy.
The estimated absolute positional accuracy of the (X,Y) coordinates of the LoD4 boundary representation, in the INSPIRE official Coordinate Reference System. Absolute positional accuracy is defined as the mean value of the positional uncertainties for a set of positions where the positional uncertainties are defined as the distance between a measured position and what is considered as the corresponding true position.
+
+
+
Description:
+
NOTE this mean value may come from quality measures on a homogeneous population of buildings or from an estimation based on the knowledge of the production processes and of their accuracy.
+
+
+
Multiplicity:
+
0..1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: LoD2MultiSurface
+
+
+
+
+
+
+
+
+
Name:
+
LoD2MultiSurface
+
+
+
Value type:
+
GM_MultiSurface
+
+
+
Definition:
+
The geometry of the boundary, corresponding to the LoD2 of CityGML.
+
+
+
Description:
+
LoD2 of City GML implies generalised geometry with vertical walls and simple roof shapes.
+
+
+
Multiplicity:
+
0..1
+
+
+
+
+
+
+
Attribute: LoD3MultiSurface
+
+
+
+
+
+
+
+
+
Name:
+
LoD3MultiSurface
+
+
+
Value type:
+
GM_MultiSurface
+
+
+
Definition:
+
The geometry of the boundary, corresponding to the LoD3 of CityGML.
+
+
+
Description:
+
LoD3 of City GML represents the exact geometry of the building, approximating its true shape.
+
+
+
Multiplicity:
+
0..1
+
+
+
+
+
+
+
Attribute: LoD4MultiSurface
+
+
+
+
+
+
+
+
+
Name:
+
LoD4MultiSurface
+
+
+
Value type:
+
GM_MultiSurface
+
+
+
Definition:
+
The geometry of the boundary, corresponding to the LoD4 of CityGML.
+
+
+
Description:
+
LoD4 of City GML represents the accurate geometry of the building, approximating its true shape.
+
+
+
Multiplicity:
+
0..1
+
+
+
+
+
+
+
Attribute: verticalGeometryEstimatedAccuracyLoD2
+
+
+
+
+
+
+
+
+
Name:
+
verticalGeometryEstimatedAccuracyLoD2
+
+
+
Value type:
+
Length
+
+
+
Definition:
+
The estimated absolute positional accuracy of the Z coordinate of the LoD2 boundary representation, in the INSPIRE official Coordinate Reference System. Absolute positional accuracy is defined as the mean value of the positional uncertainties for a set of positions where the positional uncertainties are defined as the distance between a measured position and what is considered as the corresponding true position. — NOTEThis mean value may come from quality measures on a homogeneous population of buildings or from an estimation based on the knowledge of the production processes and of their accuracy.
+
+
+
Multiplicity:
+
0..1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: verticalGeometryEstimatedAccuracyLoD3
+
+
+
+
+
+
+
+
+
Name:
+
verticalGeometryEstimatedAccuracyLoD3
+
+
+
Value type:
+
Length
+
+
+
Definition:
+
The estimated absolute positional accuracy of the Z coordinate of the LoD3 boundary representation, in the INSPIRE official Coordinate Reference System. Absolute positional accuracy is defined as the mean value of the positional uncertainties for a set of positions where the positional uncertainties are defined as the distance between a measured position and what is considered as the corresponding true position.
+
+
+
Description:
+
NOTEThis mean value may come from quality measures on a homogeneous population of buildings or from an estimation based on the knowledge of the production processes and of their accuracy.
+
+
+
Multiplicity:
+
0..1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Attribute: verticalGeometryEstimatedAccuracyLoD4
+
+
+
+
+
+
+
+
+
Name:
+
verticalGeometryEstimatedAccuracyLoD4
+
+
+
Value type:
+
Length
+
+
+
Definition:
+
The estimated absolute positional accuracy of the Z coordinate of the LoD4 boundary representation, in the INSPIRE official Coordinate Reference System. Absolute positional accuracy is defined as the mean value of the positional uncertainties for a set of positions where the positional uncertainties are defined as the distance between a measured position and what is considered as the corresponding true position.
+
+
+
Description:
+
NOTEThis mean value may come from quality measures on a homogeneous population of buildings or from an estimation based on the knowledge of the production processes and of their accuracy.
+
+
+
Multiplicity:
+
0..1
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
+
Constraint: atLeastOneMandatoryGeometry
+
+
+
+
+
+
+
+
+
Natural language:
+
+
+
+
OCL:
+
At least one of the mandatory geometries must be provided:
+
+
+
+
+
+
+
+
+
5.8.2.2.2. TextCoordGen
+
+
+
+
+
+
+
TextCoordGen
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
TextCoordGen
+
+
+
Subtype of:
+
TextureParametrization
+
+
+
Definition:
+
Way to map a texture file (2D image coordinates) to a surface of the exterior shell of a building (3D real-world coordinates), by applying a transformation between the two coordinate reference systems.
+
+
+
Stereotypes:
+
«dataType»
+
+
+
+
+
+
+
Attribute: worldToTexture
+
+
+
+
+
+
+
+
+
Name:
+
worldToTexture
+
+
+
Value type:
+
TransformationMatrix3x4
+
+
+
Definition:
+
Matrix of the transformation between the file coordinates in an image to the geographical coordinates.
+
+
+
Multiplicity:
+
1
+
+
+
+
+
+
+
+
+
5.8.2.2.3. TextCoordList
+
+
+
+
+
+
+
TextCoordList
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
TextCoordList
+
+
+
Subtype of:
+
TextureParametrization
+
+
+
Definition:
+
Way to map a texture file to a surface of the exterior shell of a building, by explicitly relating the coordinates of the image to the corresponding coordinates on the surface in the building shell.
+
+
+
Stereotypes:
+
«dataType»
+
+
+
+
+
+
+
Attribute: ring
+
+
+
+
+
+
+
+
+
Name:
+
ring
+
+
+
Value type:
+
URI
+
+
+
Definition:
+
Uniform Resource Identifier; gives indication where the ring (limit of image) may be found.
+
+
+
Multiplicity:
+
1
+
+
+
+
+
+
+
Attribute: textureCoordinates
+
+
+
+
+
+
+
+
+
Name:
+
textureCoordinates
+
+
+
Value type:
+
Number
+
+
+
Definition:
+
List of coordinates in the texture file.
+
+
+
Multiplicity:
+
0..*
+
+
+
+
+
+
+
+
+
5.8.2.2.4. TextureParametrization
+
+
+
+
+
+
+
TextureParametrization (abstract)
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
TextureParametrization
+
+
+
Definition:
+
TextureParametrization is the abstract supertype of TextCoordGen and TextCoordList. Is is used to relate both to a ParametrizedTexture.
+
+
+
Stereotypes:
+
«dataType»
+
+
+
+
+
+
+
Association role: texture
+
+
+
+
+
+
+
+
+
Value type:
+
ParameterizedTexture
+
+
+
Definition:
+
The texture to be applied to the spatial object.
+
+
+
Multiplicity:
+
0..*
+
+
+
+
+
+
+
+
+
5.8.2.2.5. TransformationMatrix3x4
+
+
+
+
+
+
+
TransformationMatrix3x4
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
TransformationMatrix3x4
+
+
+
Definition:
+
A matrix providing the transformation function between coordinates of the texture image and the geographical coordinates.
+
+
+
Stereotypes:
+
«dataType»
+
+
+
+
+
+
+
Attribute: elements
+
+
+
+
+
+
+
+
+
Name:
+
elements
+
+
+
Value type:
+
Number
+
+
+
Definition:
+
The matrix elements.
+
+
+
Multiplicity:
+
0..*
+
+
+
+
+
+
+
+
+
+
5.8.2.3. Code lists
+
+
5.8.2.3.1. InternalInstallationNatureValue
+
+
+
+
+
+
+
InternalInstallationNatureValue
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
InternalInstallationNatureValue
+
+
+
Definition:
+
Code list for the possible values of the nature of an internal installation.
The allowed values for this code list comprise the values specified in Annex C and additional values at any level defined by data providers. Annex C includes recommended values that may be used by data providers.
The allowed values for this code list comprise the values specified in Annex C and additional values at any level defined by data providers. Annex C includes recommended values that may be used by data providers.
+
+
+
+
+
+
+
+
+
5.8.2.3.3. RoomNatureValue
+
+
+
+
+
+
+
RoomNatureValue
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
RoomNatureValue
+
+
+
Definition:
+
Code list giving the possible values for the nature of a room (use or intended function).
The allowed values for this code list comprise the values specified in Annex C and additional values at any level defined by data providers. Annex C includes recommended values that may be used by data providers.
The allowed values for this code list comprise the values specified in Annex C and additional values at any level defined by data providers. Annex C includes recommended values that may be used by data providers.
+
+
+
+
+
+
+
+
+
+
5.8.2.4. Imported types (informative)
+
+
This section lists definitions for feature types, data types and code lists that are defined in other application schemas. The section is purely informative and should help the reader understand the feature catalogue presented in the previous sections. For the normative documentation of these types, see the given references.
+
+
+
5.8.2.4.1. AbstractBuildingUnit
+
+
+
+
+
+
+
AbstractBuildingUnit (abstract)
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
BuildingsExtendedBase
+
+
+
Reference:
+
INSPIRE Data specification on Buildings [DS-D2.8.III.2]
+
+
+
Definition:
+
Abstract spatial object type grouping the semantic properties of building units. A BuildingUnit is a subdivision of Building with its own lockable access from the outside or from a common area (i.e. not from another BuildingUnit), which is atomic, functionally independent, and may be separately sold, rented out, inherited, etc.
+
+
+
Description:
+
Building units are spatial objects aimed at subdividing buildings and/or building parts into smaller parts that are treated as seperate entities in daily life. A building unit is homogeneous, regarding management aspects.
+EXAMPLES: It may be e.g. an apartment in a condominium, a terraced house, or a shop inside a shopping arcade.
+NOTE 1: According to national regulations, a building unit may be a flat, a cellar, a garage or set of a flat, a cellar and a garage.
+NOTE 2: According to national regulation, a building that is one entity for daily life (typically, a single family house) may be considered as a Building composed of one BuildingUnit or as a Building composed of zero BuildingUnit.
+
+
+
+
+
+
+
+
+
5.8.2.4.2. AbstractInstallation
+
+
+
+
+
+
+
AbstractInstallation (abstract)
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
BuildingsExtendedBase
+
+
+
Reference:
+
INSPIRE Data specification on Buildings [DS-D2.8.III.2]
+
+
+
Definition:
+
Abstract spatial object type grouping the semantic properties of installations. An external construction (of small size) or an external device serving the building or building part.
+
+
+
Description:
+
EXAMPLES: stairway, solar panel, external lift
+
+
+
+
+
+
+
+
+
5.8.2.4.3. AbstractOtherConstruction
+
+
+
+
+
+
+
AbstractOtherConstruction (abstract)
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
BuildingsExtendedBase
+
+
+
Reference:
+
INSPIRE Data specification on Buildings [DS-D2.8.III.2]
+
+
+
Definition:
+
Abstract spatial object type grouping the semantic properties of other constructions. An other construction is a self-standing construction that belongs to theme Buildings and that is not a Building.
+
+
+
Description:
+
NOTE 1: the main difference between a building and an other construction is the fact that an other construction does not need to be enclosed.
+NOTE 2: the other constructions to be considered under scope of theme Buildings are the constructions that are not present in another INSPIRE theme and that are necessary for environmental use cases, such as the ones considered in this data specification.
+EXAMPLES: bridge, acoustic fence, city wall.
+
+
+
+
+
+
+
+
+
5.8.2.4.4. BuildingInfo
+
+
+
+
+
+
+
BuildingInfo (abstract)
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
BuildingsExtendedBase
+
+
+
Reference:
+
INSPIRE Data specification on Buildings [DS-D2.8.III.2]
+
+
+
Definition:
+
Abstract spatial object type grouping the additional specific properties of Building and Building Part.
+
+
+
Description:
+
NOTE 1: The additonal properties are those that are not already included in the base application schema.
+NOTE 2: The specific properties are the properties that appliy to Building and BuildingPart without applying to BuildingUnit.
+
+
+
+
+
+
+
+
+
5.8.2.4.5. DateTime
+
+
+
+
+
+
+
DateTime
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
Date and Time
+
+
+
Reference:
+
Geographic information — Conceptual schema language [ISO/TS 19103:2005]
+
+
+
+
+
+
+
+
+
5.8.2.4.6. GM_MultiSolid
+
+
+
+
+
+
+
GM_MultiSolid
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
Geometric aggregates
+
+
+
Reference:
+
Geographic information — Spatial schema [ISO 19107:2003]
+
+
+
+
+
+
+
+
+
5.8.2.4.7. GM_MultiSurface
+
+
+
+
+
+
+
GM_MultiSurface
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
Geometric aggregates
+
+
+
Reference:
+
Geographic information — Spatial schema [ISO 19107:2003]
+
+
+
+
+
+
+
+
+
5.8.2.4.8. GM_Object
+
+
+
+
+
+
+
GM_Object (abstract)
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
Geometry root
+
+
+
Reference:
+
Geographic information — Spatial schema [ISO 19107:2003]
+
+
+
+
+
+
+
+
+
5.8.2.4.9. GM_Primitive
+
+
+
+
+
+
+
GM_Primitive (abstract)
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
Geometric primitive
+
+
+
Reference:
+
Geographic information — Spatial schema [ISO 19107:2003]
+
+
+
+
+
+
+
+
+
5.8.2.4.10. GM_Solid
+
+
+
+
+
+
+
GM_Solid
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
Geometric primitive
+
+
+
Reference:
+
Geographic information — Spatial schema [ISO 19107:2003]
+
+
+
+
+
+
+
+
+
5.8.2.4.11. Identifier
+
+
+
+
+
+
+
Identifier
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
Base Types
+
+
+
Reference:
+
INSPIRE Generic Conceptual Model, version 3.4 [DS-D2.5]
+
+
+
Definition:
+
External unique object identifier published by the responsible body, which may be used by external applications to reference the spatial object.
+
+
+
Description:
+
NOTE1 External object identifiers are distinct from thematic object identifiers.
+
+NOTE 2 The voidable version identifier attribute is not part of the unique identifier of a spatial object and may be used to distinguish two versions of the same spatial object.
+
+NOTE 3 The unique identifier will not change during the life-time of a spatial object.
+
+
+
+
+
+
+
+
+
5.8.2.4.12. Length
+
+
+
+
+
+
+
Length
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
Units of Measure
+
+
+
Reference:
+
Geographic information — Conceptual schema language [ISO/TS 19103:2005]
+
+
+
+
+
+
+
+
+
5.8.2.4.13. MaterialOfFacadeValue
+
+
+
+
+
+
+
MaterialOfFacadeValue
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
BuildingsExtendedBase
+
+
+
Reference:
+
INSPIRE Data specification on Buildings [DS-D2.8.III.2]
+
+
+
Definition:
+
Code list for the possible values of MaterialOfFacade
+
+
+
+
+
+
+
+
+
5.8.2.4.14. MaterialOfRoofValue
+
+
+
+
+
+
+
MaterialOfRoofValue
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
BuildingsExtendedBase
+
+
+
Reference:
+
INSPIRE Data specification on Buildings [DS-D2.8.III.2]
+
+
+
Definition:
+
Code list for possible values of attribute MaterialOfRoof
+
+
+
+
+
+
+
+
+
5.8.2.4.15. Number
+
+
+
+
+
+
+
Number (abstract)
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
Numerics
+
+
+
Reference:
+
Geographic information — Conceptual schema language [ISO/TS 19103:2005]
+
+
+
+
+
+
+
+
+
5.8.2.4.16. URI
+
+
+
+
+
+
+
URI
+
+
+
+
+
+
+
+
+
+
+
+
Package:
+
basicTypes
+
+
+
Reference:
+
Geographic information — Geography Markup Language (GML) [ISO 19136:2007]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
6. Reference systems, units of measure and grids
+
+
+
6.1. Default reference systems, units of measure and grid
+
+
The reference systems, units of measure and geographic grid systems included in this sub-section are the defaults to be used for all INSPIRE data sets, unless theme-specific exceptions and/or additional requirements are defined in section 6.2.
+
+
+
6.1.1. Coordinate reference systems
+
+
6.1.1.1. Datum
+
+
+
+
+
📕
+
+
+
+
IR Requirement
+Annex II, Section 1.2
+Datum for three-dimensional and two-dimensional coordinate reference systems
+
+
+
For the three-dimensional and two-dimensional coordinate reference systems and the horizontal component of compound coordinate reference systems used for making spatial data sets available, the datum shall be the datum of the European Terrestrial Reference System 1989 (ETRS89) in areas within its geographical scope, or the datum of the International Terrestrial Reference System (ITRS) or other geodetic coordinate reference systems compliant with ITRS in areas that are outside the geographical scope of ETRS89. Compliant with the ITRS means that the system definition is based on the definition of the ITRS and there is a well documented relationship between both systems, according to EN ISO 19111.
+
+
+
+
+
+
+
+
6.1.1.2. Coordinate reference systems
+
+
+
+
+
📕
+
+
+
+
IR Requirement
+Annex II, Section 1.3
+Coordinate Reference Systems
+
+
+
Spatial data sets shall be made available using at least one of the coordinate reference systems specified in sections 1.3.1, 1.3.2 and 1.3.3, unless one of the conditions specified in section 1.3.4 holds.
+
+
+
1.3.1. Three-dimensional Coordinate Reference Systems
+
+
+
+
+
Three-dimensional Cartesian coordinates based on a datum specified in 1.2 and using the parameters of the Geodetic Reference System 1980 (GRS80) ellipsoid.
+
+
+
Three-dimensional geodetic coordinates (latitude, longitude and ellipsoidal height) based on a datum specified in 1.2 and using the parameters of the GRS80 ellipsoid.
+
+
+
+
+
1.3.2. Two-dimensional Coordinate Reference Systems
+
+
+
+
+
Two-dimensional geodetic coordinates (latitude and longitude) based on a datum specified in 1.2 and using the parameters of the GRS80 ellipsoid.
+
+
+
Plane coordinates using the ETRS89 Lambert Azimuthal Equal Area coordinate reference system.
+
+
+
Plane coordinates using the ETRS89 Lambert Conformal Conic coordinate reference system.
+
+
+
Plane coordinates using the ETRS89 Transverse Mercator coordinate reference system.
+
+
+
+
+
1.3.3. Compound Coordinate Reference Systems
+
+
+
+
+
+
+
For the horizontal component of the compound coordinate reference system, one of the coordinate reference systems specified in section 1.3.2 shall be used.
+
+
+
For the vertical component, one of the following coordinate reference systems shall be used:
+
+
+
+
+
+
+
+
+
For the vertical component on land, the European Vertical Reference System (EVRS) shall be used to express gravity-related heights within its geographical scope. Other vertical reference systems related to the Earth gravity field shall be used to express gravity-related heights in areas that are outside the geographical scope of EVRS.
+
+
+
For the vertical component in the free atmosphere, barometric pressure, converted to height using ISO 2533:1975 International Standard Atmosphere, or other linear or parametric reference systems shall be used. Where other parametric reference systems are used, these shall be described in an accessible reference using EN ISO 19111-2:2012.
+
+
+
For the vertical component in marine areas where there is an appreciable tidal range (tidal waters), the Lowest Astronomical Tide (LAT) shall be used as the reference surface.
+
+
+
For the vertical component in marine areas without an appreciable tidal range, in open oceans and effectively in waters that are deeper than 200 meters, the Mean Sea Level (MSL) or a well-defined reference level close to the MSL shall be used as the reference surface.
+
+
+
+
+
1.3.4. Other Coordinate Reference Systems
+
+
+
Exceptions, where other coordinate reference systems than those listed in 1.3.1, 1.3.2 or 1.3.3 may be used, are:
+
+
+
+
+
Other coordinate reference systems may be specified for specific spatial data themes.
+
+
+
For regions outside of continental Europe, Member States may define suitable coordinate reference systems.
+
+
+
+
+
The geodetic codes and parameters needed to describe these other coordinate reference systems and to allow conversion and transformation operations shall be documented and an identifier shall be created in a coordinate systems register established and operated by the Commission, according to EN ISO 19111 and ISO 19127.
+The Commission shall be assisted by the INSPIRE Commission expert group in the maintenance and update of the coordinate systems register.
+
+
+
+
+
+
+
+
6.1.1.3. Display
+
+
+
+
+
📕
+
+
+
+
IR Requirement
+Annex II, Section 1.4
+Coordinate Reference Systems used in the View Network Service
+
+
+
For the display of spatial data sets with the view network service as specified in Regulation No 976/2009, at least the coordinate reference systems for two-dimensional geodetic coordinates (latitude, longitude) shall be available.
+
+
+
+
+
+
+
+
6.1.1.4. Identifiers for coordinate reference systems
+
+
+
+
+
📕
+
+
+
+
IR Requirement
+Annex II, Section 1.5
+Coordinate Reference Systems used in the View Network Service
+
+
+
+
+
Coordinate reference system parameters and identifiers shall be managed in one or several common registers for coordinate reference systems.
+
+
+
Only identifiers contained in a common register shall be used for referring to the coordinate reference systems listed in this Section.
+
+
+
+
+
+
+
+
+
These Technical Guidelines propose to use the http URIs provided by the Open Geospatial Consortium as coordinate reference system identifiers(see identifiers for the default CRSs in the INSPIRE coordinate reference systems register). These are based on and redirect to the definition in the EPSG Geodetic Parameter Registry (http://www.epsg-registry.org/).
+
+
+
+
+
+
📒
+
+
+
+
TG Requirement 2
+
+
+
The identifiers listed in the INSPIRE coordinate reference systems register (https://inspire.ec.europa.eu/crs) shall be used for referring to the coordinate reference systems used in a data set.
+
+
+
+
+
+
+
NOTE CRS identifiers may be used e.g. in:
+
+
+
+
+
data encoding,
+
+
+
data set and service metadata, and
+
+
+
requests to INSPIRE network services.
+
+
+
+
+
+
+
6.1.2. Temporal reference system
+
+
+
+
+
📕
+
+
+
+
IR Requirement
+Article 11
+Temporal Reference Systems
+
+
+
+
+
The default temporal reference system referred to in point 5 of part B of the Annex to Commission Regulation (EC) No 1205/2008 ([14]) shall be used, unless other temporal reference systems are specified for a specific spatial data theme in Annex II.
+
+
+
+
+
+
+
+
+
NOTE 1 Point 5 of part B of the Annex to Commission Regulation (EC) No 1205/2008 (the INSPIRE Metadata IRs) states that the default reference system shall be the Gregorian calendar, with dates expressed in accordance with ISO 8601.
+
+
+
NOTE 2 ISO 8601 Data elements and interchange formats – Information interchange – Representation of dates and times is an international standard covering the exchange of date and time-related data. The purpose of this standard is to provide an unambiguous and well-defined method of representing dates and times, so as to avoid misinterpretation of numeric representations of dates and times, particularly when data is transferred between countries with different conventions for writing numeric dates and times. The standard organizes the data so the largest temporal term (the year) appears first in the data string and progresses to the smallest term (the second). It also provides for a standardized method of communicating time-based information across time zones by attaching an offset to Coordinated Universal Time (UTC).
+
+
+
EXAMPLE 1997 (the year 1997), 1997-07-16 (16th July 1997), 1997-07-16T19:20:3001:00 (16th July 1997, 19h 20' 30'', time zone: UTC1)
+
+
+
+
6.1.3. Units of measure
+
+
+
+
+
📕
+
+
+
+
IR Requirement
+Article 12
+Other Requirements & Rules
+
+
+
(…)
+
+
+
+
+
All measurement values shall be expressed using SI units or non-SI units accepted for use with the International System of Units, unless specified otherwise for a specific spatial data theme or type.
+
+
+
+
+
+
+
+
+
+
+
6.2. Theme-specific requirements and recommendations
+
+
6.2.1. Coordinate reference systems
+
+
+
+
it is not recommended to use ETRS89-XYZ for Cartesian coordinates in ETRS89, because the (X, Y, Z) coordinates used by this system are not the relevant ones to make meaningful distinction between 2D, 2,5D and 3D data
+
+
+
theme Building being used at large scale, projections offering little linear alteration should be preferred :
+
+
+
+
ETRS89-LAEA for ETRS89 coordinates projected into plane coordinates by the Lambert Azimuthal Equal Area projection
+
+
+
ETRS89-TMzn for ETRS89 coordinates projected into plane coordinates by the Transverse Mercator projection
+
+
+
+
+
+
+
+
+
+
+
📘
+
+
+
+
Recommendation 2
+
+
+
For 2D data, the two-dimensional Coordinate Reference Systems defined by theme RS should be used.
+
+
+
+
+
+
+
+
+
+
📘
+
+
+
+
Recommendation 3
+
+
+
For 2,5D and 3D data, the Compound Coordinate Reference Systems should be used preferably to the three-dimensional Coordinate Reference Systems.
+
+
+
+
+
+
+
Some vertical coordinate reference systems are obviously not relevant for theme Buildings. It is the case of the vertical reference systems that are not gravity related:
+
+
+
+
+
LAT for depth of the sea floor, where there is an appreciable tidal range
+
+
+
MSL for depth of the sea floor, in marine areas without an appreciable tidal range, in open oceans and effectively in waters that are deeper than 200m
+
+
+
ISA for pressure coordinate in the free atmosphere
+
+
+
PFO for Pressure coordinate in the free ocean
+
+
+
+
+
+
+
+
📘
+
+
+
+
Recommendation 4
+
+
+
Only gravity-related vertical coordinate reference systems should be used for theme Buildings.
+
+
+
+
+
+
+
+
6.2.2. Units of measure
+
+
NOTE Units of measure from International System shall be used for theme Buildings. Regarding values of attributes, the related requirements are expressed as constraints in the applications schemas.
+
+
+
+
+
+
+
+
7. Data quality
+
+
+
This chapter includes a description of the data quality elements and sub-elements as well as the corresponding data quality measures that should be used to evaluate and document data quality for data sets related to the spatial data theme Buildings (section 7.1).
+
+
+
It may also define requirements or recommendations about the targeted data quality results applicable for data sets related to the spatial data theme Buildings (sections 0 and 7.3).
+
+
+
In particular, the data quality elements, sub-elements and measures specified in section 7.1 should be used for
+
+
+
+
+
evaluating and documenting data quality properties and constraints of spatial objects, where such properties or constraints are defined as part of the application schema(s) (see section 5);
+
+
+
evaluating and documenting data quality metadata elements of spatial data sets (see section 8); and/or
+
+
+
specifying requirements or recommendations about the targeted data quality results applicable for data sets related to the spatial data theme Buildings (see sections 0 and 7.3).
+
+
+
+
+
The descriptions of the elements and measures are based on Annex D of ISO/DIS 19157 Geographic information – Data quality.
+
+
+
7.1. Data quality elements
+
+
Table 6 lists all data quality elements and sub-elements that are being used in this specification. Data quality information can be evaluated at level of spatial object, spatial object type, dataset or dataset series. The level at which the evaluation is performed is given in the "Evaluation Scope" column.
+
+
+
The measures to be used for each of the listed data quality sub-elements are defined in the following sub-sections.
+
+
+
Table 6 – Data quality elements used in the spatial data theme Buildings
+
+
+
+
+
+
+
+
+
+
+
+
Section
+
Data quality element
+
Data quality sub-element
+
Definition
+
Evaluation Scope
+
+
+
7.1.1
+
Completeness
+
Commission
+
excess data present in the dataset, as described by the scope
+
spatial object type
+
+
+
7.1.2
+
Completeness
+
Omission
+
data absent from the dataset, as described by the scope
+
spatial object type
+
+
+
7.1.3
+
Positional accuracy
+
Absolute or external accuracy
+
closeness of reported coordinate values to values accepted as or being true
+
spatial object type
+
+
+
7.1.4
+
Usability
+
—
+
degree of adherence of a dataset to a specific set of requirements
+
dataset
+
+
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 12
+
+
+
Where it is impossible to express the evaluation of a data quality element in a quantitative way, the evaluation of the element should be expressed with a textual statement as a data quality descriptive result.
+
+
+
+
+
+
+
7.1.1. Completeness – Commission
+
+
+
+
+
📘
+
+
+
+
Recommendation 13
+
+
+
Commission should be evaluated and documented using <error rate, from ISO/DIS 19157> as specified in the tables below.
+
+
+
+
+
+
+
NOTE this recommendation applies to any data set related to theme Buildings, whatever profile is used. In case an extended profile is used, priority should be given to report omission related to feature types Building and BuildingPart.
+
+
+
+
+
+
+
+
+
Name
+
Rate of excess items
+
+
+
Alternative name
+
–
+
+
+
Data quality element
+
Completeness
+
+
+
Data quality sub-element
+
Commission
+
+
+
Data quality basic measure
+
Error rate
+
+
+
Definition
+
Number of excess items in the dataset in relation to the number of items that should have been present.
+
+
+
Description
+
Items that should have been present are defined in the data capture rules of the data producer that have to be documented, e.g. in the template for additional information (provided in annex D)
+
+
+
Evaluation scope
+
Data set
+
+
+
Reporting scope
+
Data set
+
+
+
Parameter
+
+
+
+
Data quality value type
+
Real (e.g. percentage, ratio)
+
+
+
Data quality value structure
+
Single value
+
+
+
Source reference
+
ISO/DIS 19157 Geographic information – Data quality
+
+
+
Example
+
2% (The dataset has 2% building parts more than the ones necessary to model the universe of discourse)
+
+
+
Measure identifier
+
3 (ISO/DIS 19157:2012)
+
+
+
+
+
+
7.1.2. Completeness – Omission
+
+
+
+
+
📘
+
+
+
+
Recommendation 14
+Omission should be evaluated and documented using <error rate, from ISO/DIS 19157> as specified in the tables below.
+
+
+
+
+
+
+
NOTE this recommendation applies to any data set related to theme Buildings, whatever profile is used. In case an extended profile is used, priority should be given to report omission related to feature types Building and BuildingPart.
+
+
+
+
+
+
+
+
+
Name
+
Rate of missing items
+
+
+
Alternative name
+
–
+
+
+
Data quality element
+
Completeness
+
+
+
Data quality sub-element
+
Omission
+
+
+
Data quality basic measure
+
Error rate
+
+
+
Definition
+
Number of missing items in the dataset in relation to the number of items that should have been present.
+
+
+
Description
+
Items that should have been present are defined in the data capture rules of the data producer that have to be documented, e.g. in the template for additional information (provided in annex E)
+
+
+
Evaluation scope
+
Data set
+
+
+
Reporting scope
+
Data set
+
+
+
Parameter
+
–
+
+
+
Data quality value type
+
Real (e.g. percentage, ratio)
+
+
+
Data quality value structure
+
Single value
+
+
+
Source reference
+
ISO/DIS 19157 Geographic information – Data quality
+
+
+
Example
+
5% (The dataset has 5% less buildings than the ones necessary to model the universe of discourse)
+
+
+
Measure identifier
+
7 (ISO/DIS 19157:2012)
+
+
+
+
+
+
7.1.3. Positional accuracy – Absolute or external accuracy
+
+
+
+
+
📘
+
+
+
+
Recommendation 15
+
+
+
Absolute or external accuracy should be evaluated and documented using <Name of the measure(s), from ISO/DIS 19157> as specified in the tables below.
+
+
+
+
+
+
+
NOTE this recommendation applies to any data set related to theme Buildings, whatever profile is used.
+
+
+
+
+
+
+
+
+
Name
+
Root mean square error of planimetry
+
+
+
Alternative name
+
RMSEP
+
+
+
Data quality element
+
Positional accuracy
+
+
+
Data quality sub-element
+
Absolute or external accuracy
+
+
+
Data quality basic measure
+
Not applicable
+
+
+
Definition
+
Radius of a circle around the given point, in which the true value lies with probability P
+
+
+
Description
+
+
The true values of the observed coordinates X and Y are known as xt and yt .
+
+
+
From this the estimator
+
+
+
+
+
+
+
+
yields to the linear root mean square error of planimetry RMSEP = σ
+
+
+
+
Evaluation scope
+
data set;
+
+
+
Reporting scope
+
data set
+
+
+
Parameter
+
-
+
+
+
Data quality value type
+
Measure
+
+
+
Data quality value structure
+
Single value
+
+
+
Source reference
+
ISO/DIS 19157 Geographic information – Data quality
+
+
+
Example
+
-
+
+
+
Measure identifier
+
47 (ISO/DIS 19157:2012)
+
+
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 16
+
+
+
Absolute or external accuracy of the vertical component of feature types, should be evaluated and documented using Root mean square error as specified in the table below.
+
+
+
+
+
+
+
NOTE this recommendation applies to only to data sets related to theme Buildings and having vertical component, i.e. to data sets with 3D or 2,5D data.
+
+
+
+
+
+
+
+
+
Name
+
Root mean square error
+
+
+
Alternative name
+
RMSE
+
+
+
Data quality element
+
Positional accuracy
+
+
+
Data quality sub-element
+
Absolute or external accuracy
+
+
+
Data quality basic measure
+
Not applicable
+
+
+
Definition
+
Standard deviation, where the true value is not estimated from the observations but known a priori
+
+
+
Description
+
+
The true value of an observable Z is known as zt. From this, the estimator:
+
+
+
+
+
+
+
+
yields to the linear root mean square error RMSE = σz.
+
+
+
+
Evaluation scope
+
data set
+
+
+
Reporting scope
+
data set
+
+
+
Parameter
+
-
+
+
+
Data quality value type
+
Measure
+
+
+
Data quality value structure
+
Single value
+
+
+
Source reference
+
ISO/DIS 19157 Geographic information – Data quality
+
+
+
Example
+
-
+
+
+
Measure identifier
+
39 (ISO/DIS 19157:2012)
+
+
+
+
+
+
7.1.4. Usability
+
+
+
+
+
📘
+
+
+
+
Recommendation 17
+
+
+
Usability should be evaluated and documented using < Computation of population use case pass,Assessment of vulnerability to earthquake use case conformance> as specified in the tables below.
+
+
+
+
+
+
+
NOTE this recommendation applies to any data set related to theme Buildings, whatever profile is used.
+
+
+
+
+
+
+
+
+
Name
+
<Computation of population use case pass,>
+
+
+
Alternative name
+
+
+
+
Data quality element
+
usability element
+
+
+
Data quality sub-element
+
+
+
+
Data quality basic measure
+
correctness indicator
+
+
+
Definition
+
indication that all the requirements for computation of population are fulfilled
+
+
+
Description
+
+
R1: completeness for the buildings whose current use is residential, industrial or commerceAndServices must be better than 90%
+
+
+
R2: at least, 95 % of the buildings of interest must be represented by a GM_Surface
+
+
+
R3: the completeness and thematic accuracy on attribute numberOfFloorAboveGround must be better than 90% or the completeness and thematic accuracy on attribute heightAboveGround must be better than 90%
+
+
+
R4: the completeness and thematic accuracy on attribute currentUse must be better than 90%
+
+
+
R5: positional geometric accuracy on buildings must be better than 5 m.
+
+
+
+
Evaluation scope
+
data set
+
+
+
Reporting scope
+
data set
+
+
+
Parameter
+
+
+
+
Data quality value type
+
Boolean (true if the requirements R1 to R5 are fulfilled)
+
+
+
Data quality value structure
+
Single value
+
+
+
Source reference
+
+
+
+
Example
+
+
+
+
Measure identifier
+
+
+
+
+
+
+
+
+
+
+
+
Name
+
<Assessment of vulnerability to earthquake use case conformance>
+
+
+
Alternative name
+
+
+
+
Data quality element
+
usability element
+
+
+
Data quality sub-element
+
+
+
+
Data quality basic measure
+
correctness indicator
+
+
+
Definition
+
indication that all the requirements for assessing vulnerability to earthquake are fulfilled
+
+
+
Description
+
+
R1: completeness for the buildings having currentUse in real world should be better than 90%
+
+
+
R2: at least, 95 % of the buildings must be represented by a GM_Surface
+
+
+
R3: the completeness and thematic accuracy on attribute numberOfFloorAboveGround must be better than 90% or the completeness and thematic accuracy on attribute heightAboveGround must be better than 90%
+
+
+
R4: the date of construction must be available with resolution equivalent or better than 5 years for the buildings constructed after 1970, 10 years for buildings constructed between 1950 and 1970 , 20 years between 1930 and 1950, for at least 90% of buildings
+
+
+
R5: the completeness and thematic accuracy on attribute material of structure must be better than 90%
+
+
+
+
Evaluation scope
+
data set
+
+
+
Reporting scope
+
data set
+
+
+
Parameter
+
+
+
+
Data quality value type
+
+
A (if requirements R1 to R5 are fulfilled)
+
+
+
B (if requirements R1 to R4 are fulfilled)
+
+
+
+
Data quality value structure
+
single
+
+
+
Source reference
+
+
+
+
Example
+
+
+
+
Measure identifier
+
+
+
+
+
+
+
+
7.2. Minimum data quality requirements
+
+
No minimum data quality requirements are defined for the spatial data theme Buildings.
+
+
+
+
7.3. Recommendation on data quality
+
+
Data related to theme Buildings may be provided according several levels of detail. The level of detail has to be adapted to the use case(s).
+
+
+
The level of detail of a building data set is characterised both by the choice of the represented features and by the geometric representation of these features (mainly the positional accuracy). For instance, a data set with only buildings will not be used at the same range of scales as a data set with buildings and some of its constitutive elements (building part, building unit, walls, roofs, rooms …).
+
+
+
+
+
+
+
+
Figure 59: The scale range suitable for the feature types of theme Buildings
+
+
+
The level of detail of a building data set has to be consistent, i.e. the positional accuracy of the geometric representation has to be adapted to the scale range of the feature types the data set contains.
+
+
+
The following Table 7 gives the recommended minimum scale and accuracy for the various possible levels of detail of building data.
+
+
+
Table 7: Recommended minimum scale and accuracy for building data sets.
+
+
+
+
+
+
+
+
+
+
+
+
+
LoD 0 (2D)
+
+LoD1 (3D)
+
LoD 0 (2D)
+
+LoD1 (3D)
+
LoD 2
+
+
+
+
+
+
+
+
+
LoD2 (2D)
+
LoD2 (3D)
+
+
+
Feature types
+
Building
+
+
Building
+
+
+
BuildingPart
+
+
+
Building
+
+
+
BuildingPart
+
+
+
Installation
+
+
+
Building
+
+
+
BuildingPart
+
+
+
Installation
+
+
+
BoundarySurface
+
+
+
+
Scale
+
1/25 000
+
1/10 000
+
1/5 000
+
1/5 000
+
+
+
Accuracy
+
5 m
+
2 m
+
1 m
+
1 m
+
+
+
+
+
+
+
+
+
+
+
+
+
+
LoD 3
+
LoD4
+
+
+
+
+
+
+
LoD 3 (3D)
+
Lod4 (2D)
+
LoD4 (3D)
+
+
+
Feature types
+
+
Building
+
+
+
BuildingPart
+
+
+
Installation
+
+
+
BoundarySurface Openings
+
+
+
Building
+
+
+
BuildingPart
+
+
+
Installation
+
+
+
BuildingUnit
+
+
+
Building
+
+
+
BuildingPart
+
+
+
Installation
+
+
+
BoundarySurface Opening
+
+
+
BuildingUnit – Room
+
+
+
InternalBuildingInstallation
+
+
+
+
Scale
+
1/2 500
+
1/1 000
+
1/1 000
+
+
+
Accuracy
+
0,5 m
+
0,2 m
+
0,2 m
+
+
+
+
+
+
+
+
📘
+
+
+
+
Recommendation 5
+
+
+
A data set related to INSPIRE theme Buildings should have the minimum positional accuracy indicated in table n°2 above.
+
+
+
+
+
+
+
NOTE the recommendation must be understood as follows:
+
+
+
+
+
a data set containing only feature type Building should have an absolute positional accuracy equal or better than 5 m
+
+
+
a data set containing only feature types Building and BuildingPart should have an absolute positional accuracy equal or better than 2 m
+
+
+
a data set corresponding to LoD2 should have an accuracy better than 1 m. A data set is considered of LoD2 if it contains at least one feature type typical of LoD2 and no feature type of more detailed level (LoD3 or LoD4).
+
+
+
+
+
+
+
+
+
8. Dataset-level metadata
+
+
+
This section specifies dataset-level metadata elements, which should be used for documenting metadata for a complete dataset or dataset series.
+
+
+
NOTE Metadata can also be reported for each individual spatial object (spatial object-level metadata). Spatial object-level metadata is fully described in the application schema(s) (section 5).
+
+
+
For some dataset-level metadata elements, in particular those for reporting data quality and maintenance, a more specific scope can be specified. This allows the definition of metadata at sub-dataset level, e.g. separately for each spatial object type (see instructions for the relevant metadata element).
+
+
+
8.1. Metadata elements defined in INSPIRE Metadata Regulation
+
+
Table 8 gives an overview of the metadata elements specified in Regulation 1205/2008/EC (implementing Directive 2007/2/EC of the European Parliament and of the Council as regards metadata).
+
+
+
The table contains the following information:
+
+
+
+
+
The first column provides a reference to the relevant section in the Metadata Regulation, which contains a more detailed description.
+
+
+
The second column specifies the name of the metadata element.
+
+
+
The third column specifies the multiplicity.
+
+
+
The fourth column specifies the condition, under which the given element becomes mandatory.
+
+
+
+
+
Table 8 – Metadata for spatial datasets and spatial dataset series specified in Regulation 1205/2008/EC
+
+
+
+
+
+
+
+
+
+
+
Metadata Regulation Section
+
Metadata element
+
Multiplicity
+
Condition
+
+
+
1.1
+
Resource title
+
1
+
+
+
+
1.2
+
Resource abstract
+
1
+
+
+
+
1.3
+
Resource type
+
1
+
+
+
+
1.4
+
Resource locator
+
0..*
+
Mandatory if a URL is available to obtain more information on the resource, and/or access related services.
+
+
+
1.5
+
Unique resource identifier
+
1..*
+
+
+
+
1.7
+
Resource language
+
0..*
+
Mandatory if the resource includes textual information.
+
+
+
2.1
+
Topic category
+
1..*
+
+
+
+
3
+
Keyword
+
1..*
+
+
+
+
4.1
+
Geographic bounding box
+
1..*
+
+
+
+
5
+
Temporal reference
+
1..*
+
+
+
+
6.1
+
Lineage
+
1
+
+
+
+
6.2
+
Spatial resolution
+
0..*
+
Mandatory for data sets and data set series if an equivalent scale or a resolution distance can be specified.
+
+
+
7
+
Conformity
+
1..*
+
+
+
+
8.1
+
Conditions for access and use
+
1..*
+
+
+
+
8.2
+
Limitations on public access
+
1..*
+
+
+
+
9
+
Responsible organisation
+
1..*
+
+
+
+
10.1
+
Metadata point of contact
+
1..*
+
+
+
+
10.2
+
Metadata date
+
1
+
+
+
+
10.3
+
Metadata language
+
1
+
+
+
+
+
+
Generic guidelines for implementing these elements using ISO 19115 and 19119 are available at http://inspire.jrc.ec.europa.eu/index.cfm/pageid/101. The following sections describe additional theme-specific recommendations and requirements for implementing these elements.
+
+
+
8.1.1. Conformity
+
+
The Conformity metadata element defined in Regulation 1205/2008/EC requires to report the conformance with the Implementing Rule for interoperability of spatial data sets and services. In addition, it may be used also to document the conformance to another specification.
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 18
+
+
+
Dataset metadata should include a statement on the overall conformance of the dataset with this data specification (i.e. conformance with all requirements).
+
+
+
+
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 19
+
+
+
The Conformity metadata element should be used to document conformance with this data specification (as a whole), with a specific conformance class defined in the Abstract Test Suite in Annex A and/or with another specification.
+
+
+
+
+
+
+
The Conformity element includes two sub-elements, the Specification (a citation of the Implementing Rule for interoperability of spatial data sets and services or other specification), and the Degree of conformity. The Degree can be Conformant (if the dataset is fully conformant with the cited specification), Not Conformant (if the dataset does not conform to the cited specification) or Not Evaluated (if the conformance has not been evaluated).
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 20
+
+
+
If a dataset is not yet conformant with all requirements of this data specification, it is recommended to include information on the conformance with the individual conformance classes specified in the Abstract Test Suite in Annex A.
+
+
+
+
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 21
+
+
+
If a dataset is produced or transformed according to an external specification that includes specific quality assurance procedures, the conformity with this specification should be documented using the Conformity metadata element.
+
+
+
+
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 22
+
+
+
If minimum data quality recommendations are defined then the statement on the conformity with these requirements should be included using the Conformity metadata element and referring to the relevant data quality conformance class in the Abstract Test Suite.
+
+
+
+
+
+
+
NOTE Currently no minimum data quality requirements are included in the IRs. The recommendation above should be included as a requirement in the IRs if minimum data quality requirements are defined at some point in the future.
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 23
+
+
+
When documenting conformance with this data specification or one of the conformance classes defined in the Abstract Test Suite, the Specification sub-element should be given using the http URI identifier of the conformance class or using a citation including the following elements:
+
+
+
+
+
title: "INSPIRE Data Specification on Buildings – Draft Guidelines – <name of the conformance class>"
+
+
+
date:
+
+
+
+
dateType: publication
+
+
+
date: 2013-04-10
+
+
+
+
+
+
+
+
+
+
+
+
EXAMPLE 1: The XML snippets below show how to fill the Specification sub-element for documenting conformance with the whole data specification on Addresses v3.0.1.
EXAMPLE 2: The XML snippets below show how to fill the Specification sub-element for documenting conformance with the CRS conformance class of the data specification on Addresses v3.0.1.
Following the ISO/DIS 19157 Quality principles, if a data provider has a procedure for the quality management of their spatial data sets then the appropriate data quality elements and measures defined in ISO/DIS 19157 should be used to evaluate and report (in the metadata) the results. If not, the Lineage metadata element (defined in Regulation 1205/2008/EC) should be used to describe the overall quality of a spatial data set.
+
+
+
+
+
+
+
According to Regulation 1205/2008/EC, lineage "is a statement on process history and/or overall quality of the spatial data set. Where appropriate it may include a statement whether the data set has been validated or quality assured, whether it is the official version (if multiple versions exist), and whether it has legal validity. The value domain of this metadata element is free text".
+
+
+
The Metadata Technical Guidelines based on EN ISO 19115 and EN ISO 19119 specifies that the statement sub-element of LI_Lineage (EN ISO 19115) should be used to implement the lineage metadata element.
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 25
+
+
+
To describe the transformation steps and related source data, it is recommended to use the following sub-elements of LI_Lineage:
+
+
+
+
+
+
+
+
+
For the description of the transformation process of the local to the common INSPIRE data structures, the LI_ProcessStep sub-element should be used.
+
+
+
For the description of the source data the LI_Source sub-element should be used.
+
+
+
+
+
NOTE 1 In order to improve the interoperability, domain templates and instructions for using these free text elements (descriptive statements) may be specified here and/or in an Annex of this data specification.
+
+
+
+
8.1.3. Lineage from MD Regulation
+
+
Lineage is one of the metadata elements coming from the Implementing Rule about Metadata. According to ISO 19115, it may be sub-divided into:
+
+
+
+
+
LI-source : information about the source data used in creating the data set received by the user (the INSPIRE data set)
+
+
+
LI-process: information about events or transformations in the life of the dataset received by the user (the INSPIRE data set).
+
+
+
+
+
However, the INSPIRE data set will generally have been provided following a complex process, that may be summarised by the figure below.
+
+
+
+
+
+
+
+
+
+
+
📘
+
+
+
+
Recommendation 6
+
+
+
To fill the metadata elements Source and Process, the source should be considered as the local/national data base used to derive the INSPIRE data set and the process as the transformations carried out to make this local/national data base compliant with INSPIRE.
+
+
+
+
+
+
+
8.1.3.1. Source
+
+
+
+
8.1.3.2. Information about the source
+
+
+
+
+
+
+
+
Metadata element name
+
Information about the source
+
+
+
Definition
+
+
Information about the source data used in creating the data
+specified by the scope
+
+
+
+
ISO 19115 number and name
+
85. source
+
+
+
ISO/TS 19139 path
+
dataQualityInfo/lineage/LI_Lineage/source
+
+
+
INSPIRE obligation / condition
+
optional
+
+
+
INSPIRE multiplicity
+
0..*
+
+
+
+
Data type (and ISO 19115 no.)
+
+
92.LI_Source
+
+
+
Domain
+
+
See B.2.4.2.3. This is a complex type (lines 93-98 from ISO 19115).
+
+
+
Either the description (free text) or the sourceExtent
+
+
+
(EX_Extent) properties shall be provided.
+
+
+
+
Implementing instructions
+
Information about the source data used in creating the data specified by the scope
+
+
+
Example
+
+
+
+
Example XML encoding
+
+
+
+
Comments
+
+
This metadata element aims to supplement the Lineage
+
+
+
metadata element defined in Regulation 1205/2008/EC with a
+
+
+
precise description of data sources that have been used as
+
+
+
input to generate the INSPIRE building dataset.
+
+
+
It is recommended to describe:
+
+
+
+
+
the main characteristics of the local or national data base used to derive the INSPIRE data set: name, geographic extent, scale or level of detail, purpose, history, ….
+
+
+
for each significant INSPIRE attribute or group of attributes (geometric or semantics), a short description of the source and process
+
+
+
+
+
Example A:
+
+
+
+
+
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.
+
+
+
+
+
+
+
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.
+
+
+
+
+
Photogrametrical numerical restitution
+
+
+
" Fieldwork and later edition in office to obtain an apparent parcellary on which to incorporate the property parcellary "
+
+
+
" semantic Treatment: codification, alteration and assignment of cadastral References and labels"
+
+
+
+
+
The geometry of buildings is composed by several subparcels of different volume constructed. For every volume the number of floors is represented and it permits to build the 3D data. Also for every building, there is a scaled graphic representation of the units forming an urban real estate.
+
+
+
The data is daily updated by field work on this basis.
+
+
+
building.
+
+
+
In every FXCC the different floors and interior spaces are represented. The FXCC contains a digital photo of the building too……
+
+
+
+
+
+
+
8.1.3.3. ProcessStep
+
+
+
+
8.1.3.4. Information about events
+
+
+
+
+
+
+
+
Metadata element name
+
Information about the source
+
+
+
+
+
Definition
+
+
Information about an event or transformation in the life of a
+
+
+
dataset including the process used to maintain the dataset
+
+
+
+
ISO 19115 number and name
+
84. processStep
+
+
+
ISO/TS 19139 path
+
dataQualityInfo/lineage/LI_Lineage/processStep
+
+
+
INSPIRE obligation / condition
+
optional
+
+
+
INSPIRE multiplicity
+
0..*
+
+
+
+
Data type (and ISO 19115 no.)
+
+
86. LI_ProcessStep
+
+
+
Domain
+
+
See B.2.4.2.2. This is a complex type (lines 87-91 from ISO 19115).
+
+
+
The description (free text) property shall be provided.
+
+
+
+
Implementing instructions
+
+
+
+
Example
+
+
+
+
Example XML encoding
+
+
+
+
Comments
+
+
This metadata element aims to supplement the Lineage
+
+
+
metadata element defined in Regulation 1205/2008/EC with a
+
+
+
precise description of a process or operation that has been
+
+
+
applied to make national/local data base compliant with INSPIRE building specifications.
+
+
+
It is recommended to describe:
+
+
+
+
+
the schema transformation to make initial source compliant with INSPIRE ; possibly, provide the internet address of the transformation report, if any
+
+
+
+
+
+
+
the coordinate transformation to make initial source compliant with INSPIRE
+
+
+
+
+
+
+
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:
+
+
+
+
+
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
+
+
+
+
+
+
+
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)
+
+
+
+
+
+
+
Buildings being captured from same source and according to same process as other topographic themes, INSPIRE theme BU is geometrically consistent with other INSPIRE themes (TN, HY, AU, GN, AD) provided from the same national source (BD TOPO). Currently, no edge-matching done with neighbouring countries.
+
+
+
+
+
+
+
+
+
+
8.1.4. Temporal reference
+
+
According to Regulation 1205/2008/EC, at least one of the following temporal reference metadata sub-elements shall be provided: temporal extent, date of publication, date of last revision, date of creation.
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 26
+
+
+
It is recommended that at least the date of the last revision of a spatial data set should be reported using the Date of last revision metadata sub-element.
+
+
+
+
+
+
+
+
+
8.2. Metadata elements for interoperability
+
+
+
+
+
📕
+
+
+
+
IR Requirement
+Article 13
+Metadata required for Interoperability
+
+
+
The metadata describing a spatial data set shall include the following metadata elements required for interoperability:
+
+
+
+
+
Coordinate Reference System: Description of the coordinate reference system(s) used in the data set.
+
+
+
Temporal Reference System: Description of the temporal reference system(s) used in the data set.
+
+
This element is mandatory only if the spatial data set contains temporal information that does not refer to the default temporal reference system.
+
+
+
+
Encoding: Description of the computer language construct(s) specifying the representation of data objects in a record, file, message, storage device or transmission channel.
+
+
+
Topological Consistency: Correctness of the explicitly encoded topological characteristics of the data set as described by the scope.
+
+
This element is mandatory only if the data set includes types from the Generic Network Model and does not assure centreline topology (connectivity of centrelines) for the network.
+
+
+
+
Character Encoding: The character encoding used in the data set.
+
+
This element is mandatory only if an encoding is used that is not based on UTF-8.
+
+
+
+
Spatial Representation Type: The method used to spatially represent geographic information.
+
+
+
+
+
+
+
+
+
These Technical Guidelines propose to implement the required metadata elements based on ISO 19115 and ISO/TS 19139.
+
+
+
The following TG requirements need to be met in order to be conformant with the proposed encoding.
+
+
+
+
+
+
📒
+
+
+
+
TG Requirement 3
+
+
+
Metadata instance (XML) documents shall validate without error against the used ISO 19139 XML schema.
+
+
+
+
+
+
+
NOTE Section 2.1.2 of the Metadata Technical Guidelines discusses the different ISO 19139 XML schemas that are currently available.
+
+
+
+
+
+
📒
+
+
+
+
TG Requirement 4
+
+
+
Metadata instance (XML) documents shall contain the elements and meet the INSPIRE multiplicity specified in the sections below.
+
+
+
+
+
+
+
+
+
+
📒
+
+
+
+
TG Requirement 5
+
+
+
The elements specified below shall be available in the specified ISO/TS 19139 path.
+
+
+
+
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 27
+
+
+
The metadata elements for interoperability should be made available together with the metadata elements defined in the Metadata Regulation through an INSPIRE discovery service.
+
+
+
+
+
+
+
NOTE While this not explicitly required by any of the INSPIRE Implementing Rules, making all metadata of a data set available together and through one service simplifies implementation and usability.
+
+
+
8.2.1. Coordinate Reference System
+
+
+
+
+
+
+
+
Metadata element name
+
Coordinate Reference System
+
+
+
+
+
Definition
+
Description of the coordinate reference system used in the dataset.
+
+
+
ISO 19115 number and name
+
13. referenceSystemInfo
+
+
+
ISO/TS 19139 path
+
referenceSystemInfo
+
+
+
INSPIRE obligation / condition
+
mandatory
+
+
+
INSPIRE multiplicity
+
1..*
+
+
+
Data type(and ISO 19115 no.)
+
186. MD_ReferenceSystem
+
+
+
Domain
+
+
To identify the reference system, the referenceSystemIdentifier (RS_Identifier) shall be provided.
+
+
+
NOTE More specific instructions, in particular on pre-defined values for filling the referenceSystemIdentifier attribute should be agreed among Member States during the implementation phase to support interoperability.
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.
Description of the computer language construct that specifies the representation of data objects in a record, file, message, storage device or transmission channel
See B.2.10.4. The property values (name, version, specification) specified in section 5 shall be used to document the default and alternative encodings.
+
+
+
Implementing instructions
+
+
+
+
Example
+
+
name: <Application schema name> GML application schema
+version: version 3.0
+specification: D2.8.III.2 Data Specification on Buildings – Technical Guidelines
The method used to spatially represent geographic information.
+
+
+
ISO 19115 number and name
+
37. spatialRepresentationType
+
+
+
ISO/TS 19139 path
+
+
+
+
INSPIRE obligation / condition
+
Mandatory
+
+
+
INSPIRE multiplicity
+
1..*
+
+
+
Data type (and ISO 19115 no.)
+
B.5.26 MD_SpatialRepresentationTypeCode
+
+
+
Domain
+
+
+
+
Implementing instructions
+
+
Of the values included in the code list in ISO 19115 (vector, grid, textTable, tin, stereoModel, video), only vector, grid and tin should be used.
+
+
+
NOTE Additional code list values may be defined based on feedback from implementation.
+
+
+
+
Example
+
-
+
+
+
Example XML encoding
+
+
+
+
Comments
+
+
+
+
+
+
+
8.2.6. Data Quality – Logical Consistency – Topological Consistency
+
+
See section 8.3.2 for instructions on how to implement metadata elements for reporting data quality.
+
+
+
+
+
8.3. Recommended theme-specific metadata elements
+
+
+
+
+
📘
+
+
+
+
Recomendation 28
+
+
+
The metadata describing a spatial data set or a spatial data set series related to the theme Buildings should comprise the theme-specific metadata elements specified in Table 9.
+
+
+
+
+
+
+
The table contains the following information:
+
+
+
+
+
The first column provides a reference to a more detailed description.
+
+
+
The second column specifies the name of the metadata element.
+
+
+
The third column specifies the multiplicity.
+
+
+
+
+
Table 9 – Optional theme-specific metadata elements for the theme Buildings
+
+
+
+
+
+
+
+
+
+
Section
+
Metadata element
+
Multiplicity
+
+
+
8.3.1
+
Maintenance Information
+
0..1
+
+
+
8.3.2
+
Logical Consistency – Conceptual Consistency
+
0..*
+
+
+
8.3.2
+
Logical Consistency – Domain Consistency
+
0..*
+
+
+
8.3.2
+
Other DQ element from chapter 7
+
0..*
+
+
+
8.3.3
+
Content Information
+
0..1
+
+
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 29
+
+
+
For implementing the metadata elements included in this section using ISO 19115, ISO/DIS 19157 and ISO/TS 19139, the instructions included in the relevant sub-sections should be followed.
+
+
+
+
+
+
+
8.3.1. Maintenance Information
+
+
+
+
+
+
+
+
Metadata element name
+
Maintenance information
+
+
+
+
+
Definition
+
Information about the scope and frequency of updating
This is a complex type (lines 143-148 from ISO 19115).
+
+
+
At least the following elements should be used (the multiplicity according to ISO 19115 is shown in parentheses):
+
+
+
+
+
maintenanceAndUpdateFrequency [1]: frequency with which changes and additions are made to the resource after the initial resource is completed / domain value: MD_MaintenanceFrequencyCode:
+
+
+
updateScope [0..*]: scope of data to which maintenance is applied / domain value: MD_ScopeCode
+
+
+
maintenanceNote [0..*]: information regarding specific requirements for maintaining the resource / domain value: free text
+
+
+
+
+
+
Implementing instructions
+
+
+
+
Example
+
+
+
+
Example XML encoding
+
+
+
+
Comments
+
+
+
+
+
+
+
8.3.2. Metadata elements for reporting data quality
+
+
+
+
+
📘
+
+
+
+
Recomendation 30
+
+
+
For reporting the results of the data quality evaluation, the data quality elements, sub-elements and (for quantitative evaluation) measures defined in chapter 7 should be used.
+
+
+
+
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 31
+
+
+
The metadata elements specified in the following sections should be used to report the results of the data quality evaluation. At least the information included in the row "Implementation instructions" should be provided.
+
+
+
+
+
+
+
The first section applies to reporting quantitative results (using the element DQ_QuantitativeResult), while the second section applies to reporting non-quantitative results (using the element DQ_DescriptiveResult).
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 32
+
+
+
If a dataset does not pass the tests of the Application schema conformance class (defined in Annex A), the results of each test should be reported using one of the options described in sections 8.3.2.1 and 8.3.2.2.
+
+
+
+
+
+
+
NOTE 1 If using non-quantitative description, the results of several tests do not have to be reported separately, but may be combined into one descriptive statement.
+
+
+
NOTE 2 The sections 8.3.2.1 and 8.3.2.2 may need to be updated once the XML schemas for ISO 19157 have been finalised.
+
+
+
The scope for reporting may be different from the scope for evaluating data quality (see section 7). If data quality is reported at the data set or spatial object type level, the results are usually derived or aggregated.
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 33
+
+
+
The scope element (of type DQ_Scope) of the DQ_DataQuality subtype should be used to encode the reporting scope.
+
+
+
Only the following values should be used for the level element of DQ_Scope: Series, Dataset, featureType.
+
+
+
If the level is featureType the levelDescription/MDScopeDescription/features element (of type Set< GF_FeatureType>) shall be used to list the feature type names.
+
+
+
+
+
+
+
NOTE In the level element of DQ_Scope, the value featureType is used to denote spatial object type.
+
+
+
8.3.2.1. Guidelines for reporting quantitative results of the data quality evaluation
+
+
+
+
+
+
+
+
Metadata element name
+
See chapter 7
+
+
+
+
+
Definition
+
See chapter 7
+
+
+
ISO/DIS 19157 number and name
+
3. report
+
+
+
ISO/TS 19139 path
+
dataQualityInfo/*/report
+
+
+
INSPIRE obligation / condition
+
optional
+
+
+
INSPIRE multiplicity
+
0..*
+
+
+
Data type (and ISO/DIS 19157 no.)
+
Corresponding DQ_xxx subelement from ISO/DIS 19157, e.g. 12. DQ_CompletenessCommission
+
+
+
Domain
+
+
Lines 7-9 from ISO/DIS 19157
+
+
+
+
+
DQ_MeasureReference (C.2.1.3)
+
+
+
DQ_EvaluationMethod (C.2.1.4.)
+
+
+
DQ_Result (C2.1.5.)
+
+
+
+
+
+
Implementing instructions
+
+
+
+
nameOfMeasure
+
+
+
+
+
NOTE This should be the name as defined in Chapter 7.
+
+
+
+
+
evaluationMethodType
+
+
+
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.
+
+
+
+
+
dateTime
+
+
+
+
+
NOTE This should be data or range of dates on which the data quality measure was applied.
+
+
+
+
+
DQ_QuantitativeResult / 64. value
+
+
+
+
+
NOTE The DQ_Result type should be DQ_QuantitativeResult and the value(s) represent(s) the application of the data quality measure (39.) using the specified evaluation method (42-43.)
+
+
+
+
Example
+
See Table E.12 — Reporting commission as metadata (ISO/DIS 19157)
+
+
+
Example XML encoding
+
+
+
+
+
+
+
8.3.2.2. Guidelines for reporting descriptive results of the Data Quality evaluation
+
+
+
+
+
+
+
+
Metadata element name
+
See chapter 7
+
+
+
+
+
Definition
+
See chapter 7
+
+
+
ISO/DIS 19157 number and name
+
3. report
+
+
+
ISO/TS 19139 path
+
dataQualityInfo/*/report
+
+
+
INSPIRE obligation / condition
+
optional
+
+
+
INSPIRE multiplicity
+
0..*
+
+
+
Data type (and ISO/DIS 19157 no.)
+
Corresponding DQ_xxx subelement from ISO/DIS 19157, e.g. 12. DQ_CompletenessCommission
+
+
+
Domain
+
+
Line 9 from ISO/DIS 19157
+
+
+
+
+
DQ_Result (C2.1.5.)
+
+
+
+
+
+
Implementing instructions
+
+
+
+
DQ_DescripitveResult / 68. statement
+
+
+
+
+
NOTE The DQ_Result type should be DQ_DescriptiveResult and in the statement (68.) the evaluation of the selected DQ sub-element should be expressed in a narrative way.
+
+
+
+
Example
+
See Table E.15 — Reporting descriptive result as metadata (ISO/DIS 19157)
+
+
+
Example XML encoding
+
+
+
+
+
+
+
+
8.3.3. Content information
+
+
+
+
+
+
+
+
Metadata element name
+
<MD_ContentInformation >
+
+
+
+
+
Definition
+
description of the content of a dataset
+
+
+
ISO 19115 number and name
+
MD_ContentInformation
+
+
+
ISO/TS 19139 path
+
+
+
+
INSPIRE obligation / condition
+
optional
+
+
+
INSPIRE multiplicity
+
0..1
+
+
+
Data type (and ISO 19115 no.)
+
MD_FeatureCatalogue
+Description
+
+
+
Domain
+
MD_FeatureCatalogue
+
+
+
Implementing instructions
+
+
The purpose of this metadata element is to inform the user about the feature types and properties that are populated in the data set.
+
+
+
This has to be done by a reference to a feature catalogue including only the populated feature types and properties. It may be done by referencing the tables supplied in annex E for additional information once they have been filled by the data producer, just by ticking the populated features and properties.
+
+
+
+
Example
+
+
+
+
Example XML encoding
+
+
+
+
Comments)
+
+
+
+
+
+
+
8.3.4. Template for additional information
+
+
The data specification for theme Buildings is quite flexible and adaptable by data producers. Therefore, there is a need that users are informed about how the INSPIRE specification has been interpreted and adapted. Typically, users would need to get explanations about the specificities remaining in a data set, even once it has been made INSPIRE conformant.
+
+
+
The main information elements to be provided by data producers in complement of the INSPIRE specifications have been identified by TWG BU in annex E: template for additional information.
+
+
+
There are two ways to use this template:
+
+
+
+
+
data producer supplies to users both the INSPIRE specification and the template for additional information to complement it
+
+
+
data producer makes its own specification based on INSPIRE one by integrating the information elements supplied in the template for additional data.
+
+
+
+
+
These documents (INSPIRE specification template for additional information or customized INSPIRE specification) are dedicated to human being users; they are not supposed to provide searchable metadata elements. These documents must be made available to users in a way or another. For instance, they may at least be published on the data provider Web site. If possible, they should be made available through the download services.
+
+
+
+
+
+
+
+
9. Delivery
+
+
+
9.1. Updates
+
+
+
+
+
📕
+
+
+
+
IR Requirement
+Article 8
+Updates
+
+
+
+
+
Member States shall make available updates of data on a regular basis.
+
+
+
All updates shall be made available at the latest 6 months after the change was applied in the source data set, unless a different period is specified for a specific spatial data theme in Annex II.
+
+
+
+
+
+
+
+
+
NOTE In this data specification, no exception is specified, so all updates shall be made available at the latest 6 months after the change was applied in the source data set.
+
+
+
+
9.2. Delivery medium
+
+
According to Article 11(1) of the INSPIRE Directive, Member States shall establish and operate a network of services for INSPIRE spatial data sets and services. The relevant network service types for making spatial data available are:
+
+
+
+
+
view services making it possible, as a minimum, to display, navigate, zoom in/out, pan, or overlay viewable spatial data sets and to display legend information and any relevant content of metadata;
+
+
+
download services, enabling copies of spatial data sets, or parts of such sets, to be downloaded and, where practicable, accessed directly;
+
+
+
transformation services, enabling spatial data sets to be transformed with a view to achieving interoperability.
+
+
+
+
+
NOTE For the relevant requirements and recommendations for network services, see the relevant Implementing Rules and Technical Guidelines[15].
+
+
+
EXAMPLE 1 Through the Get Spatial Objects function, a download service can either download a pre-defined data set or pre-defined part of a data set (non-direct access download service), or give direct access to the spatial objects contained in the data set, and download selections of spatial objects based upon a query (direct access download service). To execute such a request, some of the following information might be required:
+
+
+
+
+
the list of spatial object types and/or predefined data sets that are offered by the download service (to be provided through the Get Download Service Metadata operation),
+
+
+
and the query capabilities section advertising the types of predicates that may be used to form a query expression (to be provided through the Get Download Service Metadata operation, where applicable),
+
+
+
a description of spatial object types offered by a download service instance (to be provided through the Describe Spatial Object Types operation).
+
+
+
+
+
EXAMPLE 2 Through the Transform function, a transformation service carries out data content transformations from native data forms to the INSPIRE-compliant form and vice versa. If this operation is directly called by an application to transform source data (e.g. obtained through a download service) that is not yet conformant with this data specification, the following parameters are required:
+
+
+
Input data (mandatory). The data set to be transformed.
+
+
+
+
+
Source model (mandatory, if cannot be determined from the input data). The model in which the input data is provided.
+
+
+
Target model (mandatory). The model in which the results are expected.
+
+
+
Model mapping (mandatory, unless a default exists). Detailed description of how the transformation is to be carried out.
+
+
+
+
+
+
9.3. Encodings
+
+
The IRs contain the following two requirements for the encoding to be used to make data available.
+
+
+
+
+
+
📕
+
+
+
+
IR Requirement
+Article 7
+Encoding
+
+
+
1. Every encoding rule used to encode spatial data shall conform to EN ISO 19118. In particular, it shall specify schema conversion rules for all spatial object types and all attributes and association roles and the output data structure used.
+
+
+
2. Every encoding rule used to encode spatial data shall be made available.
+
+
+
2a. Every encoding rule used to encode spatial data shall also specify whether and how to represent attributes and association roles for which a corresponding value exists but is not contained in the spatial data sets maintained by a Member State, or cannot be derived from existing values at reasonable costs.
+
+
+
+
+
+
+
NOTE ISO 19118:2011 specifies the requirements for defining encoding rules used for interchange of geographic data within the set of International Standards known as the "ISO 19100 series". An encoding rule allows geographic information defined by application schemas and standardized schemas to be coded into a system-independent data structure suitable for transport and storage. The encoding rule specifies the types of data being coded and the syntax, structure and coding schemes used in the resulting data structure. Specifically, ISO 19118:2011 includes
+
+
+
+
+
requirements for creating encoding rules based on UML schemas,
+
+
+
requirements for creating encoding services, and
+
+
+
requirements for XML-based encoding rules for neutral interchange of data.
+
+
+
+
+
While the IRs do not oblige the usage of a specific encoding, these Technical Guidelines propose to make data related to the spatial data theme Buildings available at least in the default encoding(s) specified in section 9.3.1. In this section, a number of TG requirements are listed that need to be met in order to be conformant with the default encoding(s).
+
+
+
The proposed default encoding(s) meet the requirements in Article 7 of the IRs, i.e. they are conformant with ISO 19118 and (since they are included in this specification) publicly available.
+
+
+
9.3.1. Default Encoding(s)
+
+
9.3.1.1. Specific requirements for GML encoding
+
+
This data specification proposes the use of GML as the default encoding, as recommended in sections 7.2 and 7.3 of [DS-D2.7]. GML is an XML encoding in compliance with ISO 19118, as required in Article 7(1). For details, see [ISO 19136], and in particular Annex E (UML-to-GML application schema encoding rules).
+
+
+
The following TG requirements need to be met in order to be conformant with GML encodings.
+
+
+
+
+
+
📒
+
+
+
+
TG Requirement 6
+
+
+
Data instance (XML) documents shall validate without error against the provided XML schema.
+
+
+
+
+
+
+
NOTE 1 Not all constraints defined in the application schemas can be mapped to XML. Therefore, the following requirement is necessary.
+
+
+
NOTE 2 The obligation to use only the allowed code list values specified for attributes and most of the constraints defined in the application schemas cannot be mapped to the XML sch. They can therefore not be enforced through schema validation. It may be possible to express some of these constraints using other schema or rule languages (e.g. Schematron), in order to enable automatic validation.
+
+
+
+
9.3.1.2. Default encoding(s) for application schema BuildingsBase
+
+
Name: BuildingsBase GML Application Schema
+Version: version 3.0
+Specification: D2.8.III.2 Data Specification on Buildings – Technical Guidelines
+Character set: UTF-8
It is recommended that also the encodings specified in this section be provided for the relevant application schemas.
+
+
+
+
+
+
+
9.3.2.1. Alternative encoding for application schema BuildingsExtended3D
+
+
9.3.2.1.1. Context- rationale
+
+
The two 3D profiles of the INSPIRE building model (Core 3D profile and Extended 3D profile) share many properties with CityGML, particularly the representation of the 3D geometry. Currently, there are many tools which support CityGML (see Gröger & Plümer 2012 or www.citygmlwiki.org for details): data capturing tools providing output data in CityGML format, visualization tools which offer CityGML as input format, tools for checking consistency, Web Feature Services which read and provide CityGML, and data bases which store data based on CityGML and provide corresponding interfaces. Due to an increasing international usage and availability of CityGML in many cities and municipalities in Europe, the Middle East and Asia as well as in various organizations and universities all over Europe this list of tools is expected to grow significantly in the future.
+
+
+
However, these CityGML tools cannot be used directly for INSPIRE building data, since the standard encodings of the four INSPIRE profiles differ from the CityGML encoding, even if the conceptual INSPIRE application schemas widely use the CityGML concepts. In order to utilize these tools also for INSPIRE building data, an alternative encoding based on CityGML is provided here.
+
+
+
CityGML provides a mechanism for adding application specific extensions to the CityGML model. This mechanism is called Application Domain Extension (ADE). An ADE is a sub-schema of CityGML through which new attributes, geometries, and relations can be added to existing CityGML classes such as the number of dwellings to the class AbstractBuilding. Moreover, also new classes can be added to the CityGML model such as OtherConstruction. These new classes typically are sub-classes of appropriate CityGML classes (e.g., of Building or of the topmost class CityObject). An ADE is an application schema in its own namespace, which imports the XML schema definitions of relevant CityGML modules. Formally, an ADE is specified as an XML schema, enabling the validation of instance documents against this schema. Examples for existing CityGML ADEs are the NoiseADE for noise simulation and mapping, the facility management ADE, the UtilityNetworkADE, and the HydroADE for hydrographical applications. Furthermore, the new national geospatial standard in the Netherlands which integrates 2D and 3D data is implemented as CityGML ADE.
+
+
+
+
9.3.2.1.2. Narrative description
+
+
A CityGML ADE currently is provided for the Core 3D profile (application schema Buildings3D) of the INSPIRE building model. An ADE for the Extended 3D profile (application schema BuildingsExtended3D) is in preparation. In these ADEs, those properties which are shared by INSPIRE and CityGML are inherited from CityGML, while properties which are different or additional in INSPIRE are defined in the CityGML ADE for INSPIRE. Constraints are employed to describe these definitions and settings. For more details on the CityGML ADE for the INSPIRE Core 3D profile, see Gröger, Kutzner & Kolbe (2013).
+
+
+
The UML diagram of the CityGML ADE for the Core 3D profile is depicted in Figure 60 and Figure 61, and the conceptual mapping between the UML classes Building and BuildingPart of the INSPIRE Core 3D profile and their encoding (GML object elements and types) in Table 10. In the left part of Figure 60, the classes AbstractBuilding, Building and BuildingPart from the CityGML Building module are shown. The attributes and relations which are specific to INSPIRE are provided by the ADE class AbstractBuilding in the INSPIRE::ADE::Core3D package. These attributes and relations are added to the CityGML class AbstractBuilding (and hence, to its sub-classes Building and BuildingPart) in the CityGML::Building package by the so-called hooking mechanism. This mechanism is indicated by the generalization relation marked with the stereotype «ADE»: the triangle points to the class receiving the attributes and relations from the ADE class AbstractBuilding at the other side of the generalization relation which is labeled with the stereotype «ADEElement». Hence, all attributes and relations of the ADE class AbstractBuilding (in ADE namespace) are added to the CityGML class AbstractBuilding (CityGML namespace). The approach how to represent the hooking mechanism in UML is described in van den Brink, Stoter & Zlatanova (2012).
+
+
+
Those attributes and relations which are common to both the CityGML building module and the INSPIRE Building module (with regard to semantics and data types) are represented by CityGML. An example is the number of storeys above ground (storeysAboveGround). Those attributes and relations which are specific to INSPIRE and for which no CityGML counterpart is available, or which differ from CityGML with regard to semantics or data type, are represented by the CityGML ADE for Core 3D (class AbstractBuilding). The constraint 'Mapping of INSPIRE Buildings to CityGML or to the INSPIRE Core 3D ADE' included in the UML diagram as well as Table 11 define this mapping. The INSPIRE properties and data types which represent geometry (properties geometry3DLoD1, geometry3DLoD2, …, data types BuildingGeometry3DLoD1, …) have been split: The pure 3D geometry is represented by CityGML properties (lod1Solid, lod2Solid, …), whereas metadata such as accuracy is provided by the INSPIRE data types mgeometry3DMetadataLoD1, geometry3DMetadataLoD1, …), c.f. Figure 61.
+
+
+
In CityGML, a BuildingPart may again have BuildingParts, whereas in INSPIRE parts of parts are not allowed. Furthermore, in CityGML there is no mandatory geometry in the class AbstractBuilding. This is in contrast to INSPIRE, where BuildingParts and Buildings without BuildingParts must have at least one geometry. Therefore, two constrains have been added to enforce the INSPIRE behavior.
+
+
+
Note that in the UML diagram, the classes Building and BuildingPart are not necessary for deriving the ADE; they have been included only to make the diagram more understandable.
+
+
+
As an example for the CityGML ADE encoding for the Core 3D profile, an instance document representing a simple building is given in Figure 63.
+
+
+
The ADE provides a practicable alternative to the native INSPIRE encoding, enabling INSPIRE building data not only to be identified and processed by currently available CityGML software as CityGML Building objects, but also to be combined with other ADEs extending the CityGML Building feature type. Furthermore, the conceptual mapping between the INSPIRE Core 3D profile and the CityGML ADE for Core 3D as described in Table 10 and Table 11 can serve in deriving INSPIRE building data directly from CityGML data and vice versa, creating views in this way. This means, when CityGML data is imported into an INSPIRE data base, the conceptual mapping describes which data have to be read and processed by the importing tool and which data can be skipped. The same holds true when INSPIRE building data is exported to CityGML data.
+
+
+
The INSPIRE Core 3D ADE has been developed by the TWG on Buildings in cooperation with the Chair of Geoinformatics at Technische Universität München and the Chair of Geoinformation, Institute for Geodesy and Geoinformation at University of Bonn, Germany.
+
+
+
The CityGML ADE for the INSPIRE Extended 3D profile is under preparation and will be supplied and tested by the wider stakeholder community as part of the INSPIRE Maintenance and Implementation Framework.
+
+
+
+
+
+
+
+
Figure 60: UML diagram (main types) of the CityGML ADE for the Core 3D profile as an alternative encoding.
+
+
+
Table 10: Mappings between conceptual UML classes and the associated GML object elements, ML Schema types and GML property types
+
+
+
+
+
+
+
+
+
+
+
UML class
+
GML element
+
GML type
+
GML property
+
+
+
+
+
INSPIRE::
+Core3D::Building
+
CityGML/building:
+Building
+
CityGML/building:
+BuildingType
+
n. a.
+
+
+
INSPIRE::
+Core3D::BuildingPart
+
CityGML/building:
+BuildingPart
+
CityGML/building:
+BuildingPartType
+
n. a.
+
+
+
+
+
+
+
+
+
+
Figure 61: UML diagram (data types) of the CityGML ADE for INSPIRE Core 3D profile as an alternative encoding.
+
+
+
Table 11: Conceptual mapping between the UML classes, attributes and relations of the INSPIRE Core3D profile and the associated UML classes, attributes and relations of the INSPIRE Core3D CityGML ADE
Figure 62: Example instance document for the CityGML ADE for the INSPIRE Core 3D profile
+
+
+
+
+
+
+
+
+
+
10. Data Capture
+
+
+
This chapter does not aim to define data capture rules as INSPIRE is based on existing data. The data capture rules of source data are up to each data producer. Data producers should clearly describe any deviations from these guidelines in the metadata. This chapter aims to give some guidelines about how to match existing data to INSPIRE specifications. It is not exhaustive but focus on the aspects that are expected to raise some issues.
+
+
+
10.1. Scope of theme Buildings
+
+
10.1.1. Purpose
+
+
Existing data should be made compliant to INSPIRE, taking into account cost-benefit considerations. The scope of theme Buildings and definition of its core feature type Building are rather generic and may open the door to various interpretations.
+
+
+
The costs of transformation will depend on how data related to theme Buildings is organised within a Member State. For instance, some data producers have all constructions in a single feature type whereas other data producers have different feature types for buildings, for annex constructions, for urban furniture …. ; building related data may be scattered between various producers or may be under the responsibility of only one organisation. Making whole scope of theme Buildings compliant to INSPIRE will likely be easier when all data regarding buildings and constructions is within the same feature type or at least in the same data set.
+
+
+
This paragraph aims to clarify the interpretation of scope, to provide recommendations about which kinds of buildings and constructions are expected by INSPIRE and so, to assess the benefits of making data compliant to INSPIRE.
+
+
+
The general rules or priority are given by the modular scope defined in clause 2.2.
+
+
+
+
+
+
+
+
Figure 63: The modular approach for scope of theme Buildings
+
+
+
+
10.1.2. Code lists
+
+
The possible values provided in the code lists on current use and on nature of buildings and constructions, provide the general guidelines about what is expected by / should be in INSPIRE.
+
+
+
More accurately:
+
+
+
+
+
The buildings hosting human activities, i.e. buildings whose current use is residential, agriculture, industrial, commerceAndservices are necessary for / strongly expected by many INSPIRE use cases.
+
+
+
The buildings whose current use is ancillary are useful for / expected by some INSPIRE use cases.
+
+
+
The buildings that may be obstacles or valuable landmarks for air traffic, i.e. those whose building nature is arch, dam, tower, lighthouse, silo, windmill, wind turbine, transformer, stadium, storageTank are necessary for / strongly expected by some INSPIRE use cases, air traffic being an international use case.
+
+
+
The buildings whose building nature takes other values (e.g. shed, greenhouse, bunker, canopy, chapel, caveBuilding…) are useful for / expected by some INSPIRE use cases (landscape description, mapping).
+
+
+
The other constructions are also necessary for / strongly expected by some INSPIRE use cases:
+
+
+
elevated constructions (crane, antenna, monument, pylons, …) as obstacles for air traffic
+
+
+
environmental barriers (protectiveStructure, acousticFence, retainingWall) or open air pools for mitigation of risk and of pollution
+
+
+
bridges and tunnels for planning of rescue itineraries in case of disaster.
+
+
+
+
+
NOTE according to the modular scope, other constructions are under the second priority, due to the expected feasibility issues, but there are quite strong user requirements about these constructions.
+
+
+
+
+
+
📘
+
+
+
+
Recommendation 7
+
+
+
OtherConstructions should be made available for INSPIRE, as much as possible.
+
+
+
+
+
+
+
+
10.1.3. Definition of theme buildings
+
+
Considered as under scope of the theme Buildings are constructions above and/or underground which are intended or used for the shelter of humans, animals, things, the production of economic goods or the delivery of services and that refer to any structure permanently constructed or erected on its site.
+
+
+
NOTE 1: According to the definition, the construction should be permanently constructed or erected on its site. However, the notion of "permanence" may be interpreted in a flexible way. For instance, some types of dwellings are theoretically designed to be mobile (e.g. mobile homes, caravans) or to be used for short time (huts, cabins, shacks, shanties) but are in practice used in permanent way and may require the set up of public services. Moreover, there are strong user requirements for data about precarious habitat (vulnerability to natural risks, improvement of habitat ….).
+
+
+
+
+
+
📘
+
+
+
+
Recommendation 8
+
+
+
A construction that is considered as permanent enough to be captured in existing data should be published for INSPIRE theme Buildings, especially if the construction hosts human activities.
+
+
+
+
+
+
+
NOTE 2: All buildings, whatever their size is, are in the scope of theme Buildings. As explained in clause 1.2.2, the scope is modular with first priority to the big or normal buildings. However, there are exceptions where small buildings are of great interest, such as a hut in mountainous area that may be a valuable landmark or shelter for hikers. Once again, this is generally already taken into account by the capture rules of data producers.
+
+
+
NOTE 3: The construction must be above or underground, i.e. it must have a significant height. This excludes "flat" constructions such as roads, railways that should be reported in INSPIRE theme Transport. On the opposite, constructions that are totally or partly underground (bunker, underground stations, underground car parks, swimming pools…) are under scope of theme Building and should be published for INSPIRE, if data is available.
+
+
+
NOTE 4: The constructions that are not buildings and that are already in another INSPIRE theme should generally not be included in the scope of theme Buildings, except if attributes typical to theme Buildings, such as height or date of construction are required by use cases.
+
+
+
+
+
10.2. Use of Building and BuildingPart
+
+
10.2.1. When to split a Building into BuildingParts?
+
+
BuildingPart is generally used for buildings that are not homogeneous, regarding attributes related to physical aspects (such as height above or below ground , height below ground, number of floors above or under ground, roof type), temporal aspects (such as year of construction) or functional aspects (building nature or current use). A BuildingPart may be used for a contiguous part of a building of which one or more attributes (except identifier and geometry) differ from all other parts it touches.
+
+
+
EXAMPLE 1:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Real world building
+
The Building may be split into 2 BuildingParts A and B because of different height above ground (e.g. 8 m for A, 6m for B)
+
The building may be represented just as single generalised Building (e.g. with height above ground = 8 m)
+
+
+
+
+
Figure 64: Split into building parts (example 1)
+
+
+
EXAMPLE 2:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Real world building
+
This Building may be split into 3 BuildingParts A, B and C because of different number of floor above ground (e.g. 20 floors for A and B, 5 floors for B)
+
The building may be represented just as single generalised Building (e.g. with number of floors above ground = 20)
+
+
+
+
+
Figure 65: Split into building parts (example 2)
+
+
+
EXAMPLE 3:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Real world building
+
This Building may be split into 2 BuildingParts A and B because of different current use (agriculture for A, residential for B)
+
The building may be represented just as single generalised Building with current use = \{residential, agriculture}
+
+
+
+
+
Figure 66: Split into building parts (example 3)
+
+
+
EXAMPLE 4:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Real world building
+
This Building may be split into 2 BuildingParts A and B because of different date of construction (e.g. 1920 for A, 1950 for B) and roof type (gable roof for A, pavillon roof for B)
+
The building may be represented just as single generalised Building with date of construction = 1920 (and date of renovation = 1950 if enlargement is considered as renovation)
+
+
+
+
+
Figure 67: Split into building parts (example 4)
+
+
+
+
10.2.2. How to split a Building into BuildingParts?
+
+
This data model is quite flexible. It is up to the data capture rules of each data producer to define the relevant building parts. These rules should be explained in the template for additional information.
+
+
+
+
+
+
+
+
Figure 68: Example from Germany
+
+
+
On the previous figure, the building has been split into 3 building parts, with complete overlap between building parts A and B.
+
+
+
+
+
+
+
+
+
+
+
+
A
+
B
+
C
+
+
+
+
+
Number of floors above ground
+
3
+
0
+
0
+
+
+
Number of floors below ground
+
0
+
1
+
1
+
+
+
+
+
EXAMPLE 2:
+
+
+
+
+
+
+
+
Figure 69: Example from Spain
+
+
+
On the previous figure, the building (two blocks of flats sharing common basement) has been split into 3 non overlapping building parts
+
+
+
+
+
+
+
+
+
+
+
+
A
+
B
+
C
+
+
+
+
+
Number of floors above ground
+
8
+
0
+
8
+
+
+
Number of floors below ground
+
3
+
3
+
3
+
+
+
+
+
EXAMPLE 3
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
This building has been split into 3 building parts
+
This building has been split into 4 building parts
+
+
+
+
+
Figure 70: Building parts with various floor distributions.
+
+
+
+
+
+
+
+
+
+
+
+
+
A
+
B
+
C
+
+
+
+
+
+
Floor distribution
+
[0,21]
+
[0,12], [18, 21]
+
[0, 21]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
A
+
B1
+
B2
+
C
+
+
+
+
+
Floor distribution
+
[0,21]
+
[0,12]
+
[18, 21]
+
[0, 21]
+
+
+
+
+
+
10.2.3. How to fill the attributes of Building and BuildingPart?
+
+
+
+
The mandatory attributes inspireId and geometry have to be filled on both Building and BuildingPart.
+
+
+
If available, the attributes beginLifespanVersion and beginLifespanVersion have also to be filled on both Building and BuildingPart.
+
+
+
If available, the attributes numberOfDwellingsand numberOfBuildingUnits may be filled on both Building and BuildingPart with the consistency rules:
+
+
+
+
number of dwelling on Building = sum of number of dwellings of the BuildingParts composing the Building
+
+
+
similar rule with numberOfBuildingUnit
+
+
+
+
+
+
Among the other attributes:
+
+
+
+
The specific attributes shall and can be filled only on Building Parts
+
+
+
The common attributes should be filled only on Buildings.
+
+
+
+
+
+
+
+
+
+
10.3. Geometric representation
+
+
10.3.1. Multiple representation
+
+
The INSPIRE model is quite flexible as it allows multiple representations for buildings and building parts. However, not all allowed representations are meaningful and relevant for any kind of buildings.
+
+
+
EXAMPLE:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Real-world building
+
Building represented by above ground envelope
+
Building represented by foot print and roof edge
+
+
+
Above ground envelope geometry is relevant
+
The representation by above ground envelope geometry is less relevant than the representation by footprint and roof edge.
+
+
+
+
+
Figure 71: Various geometric representations of buildings
+
+
+
+
+
+
📘
+
+
+
+
Recommendation 9
+
+
+
Data producers should publish for INSPIRE the most relevant geometric representation(s) of buildings and building parts.
+
+
+
+
+
+
+
NOTE The representation of envelope geometries by 2,5D data may raise issues; typically, the Z value may be not very meaningful.
+
+
+
+
10.3.2. Missing Z and 2,5D data
+
+
Some existing data sets may include both 2,5 D and 2D data. This is typically the case for data sets where most buildings are captured by stereo-plotting with Z coordinate (i.e. as 2,5D data) whereas some others are captured by other ways (e.g. from existing maps or from orthoimages) without the Z coordinate (i.e. as 2D data).
+
+
+
This case may be avoided if the data producer can wrap the buildings on a DTM and so, can attribute to the building geometric representation a reasonable Z value at ground level; the vertical geometry accuracy enables to document the process approximation.
+
+
+
Nevertheless, for cases where there are still missing Z values on some buildings, the general rule is to attach the Coordinate Reference System at feature level (instead of declaring it for the whole data set):
+
+
+
+
+
Buildings captured as 2,5D data will be attached with a 3D Coordinate Reference System
+
+
+
Buldings captured as 2D data will be attached with a 2D Coordinate Reference System
+
+
+
+
+
Normally, the 3D Coordinate Reference System will be a compound system whose 2D component is the same Coordinate Reference System as the one used for the buildings captured as 2D data.
+
+
+
An alternative solution would be to provide 2D and 2,5D buildings in different data sets.
+
+
+
+
+
10.4. Mapping examples for attribute currentUse
+
+
The principle is to match at the most detailed level as possible. Some approximate mappings are acceptable and even necessary. However, they should be reported in the template for additional information (Annex E)
+
+
+
Example 1: from Dutch Dwelling Register to INSPIRE
+
+
+
+
+
+
+
+
Figure 72: Matching example from national classification to INSPIRE classification of current use
+
+
+
Example 2 : from Eurostat classification to INSPIRE
+
+
+
+
+
+
+
+
Figure 73: Matching example from EUROSTAT classification to INSPIRE classification of current use
+
+
+
NOTE 1: some data producers have already implemented the Eurostat classification.
+
+
+
+
10.5. Temporal aspects
+
+
+
+
+
+
+
Figure 74: Temporal aspects
+
+
+
The INSPIRE UML schema includes 6 attributes that are related to the temporal aspects:
+
+
+
+
+
conditionOfConstruction: current condition of the construction or building
+
+
+
date of construction, date of renovation and date of demolition that are related to respective events in the real world
+
+
+
beginLifespanVersion and endLifespanVersion that are related to the events in the dataset (e.g. when a construction was inserted in the data set or when it was depreciated).
+
+
+
+
+
10.5.1. Data type DateOfEvent
+
+
+
+
+
+
+
Figure 75: Data type DateOfEvent
+
+
+
The data type DateOfEvent enables to supply temporal information about an event (construction, renovation, demolition) in the following cases:
+
+
+
+
+
a data producer has the date of the event but without any other information about which phase of the event the date refers to
+
+
+
a data producer does not have the date of the event but has the information as an interval (e.g. before 1950, between 1800 and 1900); this case applies mainly for old buildings
+
+
+
a data producer has several dates corresponding to different points of the event, e.g. the beginning and the end of the event.
+
+
+
+
+
EXAMPLES (for date of construction)
+
+
+
+
+
producer knows that construction date is 1978
+
+
+
+
beginning: void
+
+
+
end: void
+
+
+
anyPoint: 1978
+
+
+
+
+
+
producer knows that construction took place before 1950
+
+
+
+
beginning: void
+
+
+
end: 1950
+
+
+
anyPoint: void
+
+
+
+
+
+
producer knows that construction took place between 1800 and 1900
+
+
+
+
beginning: 1800
+
+
+
end: 1900
+
+
+
anyPoint: void
+
+
+
+
+
+
producer knows that construction took place between 12/04/2008 and 25/12/2010
+
+
+
+
beginning: 12/04/2008
+
+
+
end :25/12/2010
+
+
+
anyPoint: void
+
+
+
+
+
+
+
+
+
10.5.2. Demolished Buildings
+
+
There are two ways to deal with demolished constructions or buildings.
+
+
+
EXAMPLE: a building that was functional was demolished on 20/03/2010 and this information is integrated by data producer on the 15/05/2010
+
+
+
+
+
first method: the building is considered as depreciated (no valid any longer)
+
+
+
+
its attribute endLifespanVersion gets value "15/05/2010"
+
+
+
its attribute dateOfDemolition gets value "20/03/2010"
+
+
+
the other attributes stay as they are, describing the building as it was just before being demolished (e.g. its attribute conditionOfConstruction remains "functional")
+
+
+
+
+
+
second method: the building is versioned in the database :
+
+
+
+
the attribute endLifespanVersion of the old version of the building will get value "15/05/2010"
+
+
+
the attribute dateOfDemolition of the old version remains empty
+
+
+
the other attributes stay as they are, describing the building as it was just before being demolished (e.g. its attribute conditionOfConstruction remains "functional")
+
+
+
the attribute beginLifespanVersion of the new version of the building will get value "15/05/2010"
+
+
+
the attribute endLifespanVersion of the new version of the building remains empty
+
+
+
the attribute conditionOfConstruction of the new version will get value "demolished"
+
+
+
the attribute dateOfDemolition of the new version will get value "20/03/2010"
+
+
+
+
+
+
+
+
The second method is well adapted for the data sets that aim to manage historical buildings whereas the first one is probably better for data sets that aim to manage current buildings.
+
+
+
+
+
10.6. Estimated accuracy
+
+
For INSPIRE, buildings shall be published in the Coordinate Reference System mandated by the Implementing Rule on Reference Systems, i.e. in ETRS89 for areas on the Eurasian tectonic plate and in ITRS elsewhere.
+
+
+
Of course, INSPIRE users will be interested by having information about the accuracy of building data, as they receive them, in the Coordinate Reference System mandated by INSPIRE. It is why the clauses about application schema and about quality and metadata require building data providers to give estimated accuracy related to the coordinates in ETRS89 (or ITRS).
+
+
+
However, in most Member States, the estimated accuracy is generally known in the source Coordinate Reference System, the national or local one.
+
+
+
The estimated accuracy for INSPIRE will be the combination of estimated accuracy in original Coordinate Reference System and of the accuracy of the coordinate transformation between original Reference System to INSPIRE Reference System.
+
+
+
Coordinate transformation between two horizontal geodetic datum is generally done, using one of the three following methods:
+
+
+
+
+
transformation with 3 parameters
+
+
+
transformation with 7 parameters
+
+
+
transformation with a grid.
+
+
+
+
+
Experience in some countries has shown that transformation with 3 or even 7 parameters might bring deviations up to 10 metres. So, the impact of such transformations may not be neglected on building data whose original accuracy generally varies from some decimetres to some metres.
+
+
+
The ideal solution would be for each Member State to define good quality coordinate transformations (using grids and bringing no deviation bigger than some centimetres). However, if not possible before the deadlines of INSPIRE, the impact of coordinate transformation has to be taken into account when giving information about positional accuracy, both in the application schema and in metadata.
+
+
+
+
+
+
+
11. Portrayal
+
+
+
This clause defines the rules for layers and styles to be used for portrayal of the spatial object types defined for this theme. Portrayal is regulated in Article 14 of the IRs.
+
+
+
+
+
+
📕
+
+
+
+
IR Requirement
+Article 14
+Portrayal
+
+
+
+
+
For the portrayal of spatial data sets using a view network service as specified in Commission Regulation No 976/2009 ([16]), the following shall be available:
+
+
+
+
the layers specified in Annex II for the theme or themes the data set is related to;
+
+
+
for each layer at least a default portrayal style, with as a minimum an associated title and a unique identifier.
+
+
+
+
+
+
+
+
+
+
For each layer, Annex II defines the following:
+
+
+
+
a human readable title of the layer to be used for display in user interface;
+
+
+
the spatial object type(s), or sub-set thereof, that constitute(s) the content of the layer.
+
+
+
+
+
+
+
+
+
+
+
+
In section 11.1, the types of layers are defined that are to be used for the portrayal of the spatial object types defined in this specification. A view service may offer several layers of the same type, one for each dataset that it offers data on a specific topic.
+
+
+
NOTE The layer specification in the IRs only contains the name, a human readable title and the (subset(s) of) spatial object type(s), that constitute(s) the content of the layer. In addition, these Technical Guidelines suggest keywords for describing the layer.
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 35
+
+
+
It is recommended to use the keywords specified in section in the Layers Metadata parameters of the INSPIRE View service (see Annex III, Part A, section 2.2.4 in Commission Regulation (EC) No 976/2009).
+
+
+
+
+
+
+
Section 10.2 specifies one style for each of these layers. It is proposed that INSPIRE view services support this style as the default style required by Article 14(1b).
+
+
+
+
+
+
📒
+
+
+
+
TG Requirement 7
+
+
+
For each layer specified in this section, the styles defined in section 10.2 shall be available.
+
+
+
+
+
+
+
NOTE The default style should be used for portrayal by the view network service if no user-defined style is specified in a portrayal request for a specific layer.
+
+
+
In section 10.3, further styles can be specified that represent examples of styles typically used in a thematic domain. It is recommended that also these styles should be supported by INSPIRE view services, where applicable.
+
+
+
+
+
+
📘
+
+
+
+
Recomendation 36
+
+
+
In addition, it is recommended that, where applicable, INSPIRE view services also support the styles defined in section 10.3.
+
+
+
+
+
+
+
Where XML fragments are used in the following sections, the following namespace prefixes apply:
+
+
+
+
+
sld="http://www.opengis.net/sld" (WMS/SLD 1.1)
+
+
+
se="http://www.opengis.net/se" (SE 1.1)
+
+
+
ogc="http://www.opengis.net/ogc" (FE 1.1)
+
+
+
+
+
11.1. Layers to be provided by INSPIRE view services
+
+
+
+
+
+
+
+
+
+
Layer Name
+
Layer Title
+
Spatial object type(s)
+
Keywords
+
+
+
+
+
BU.Building
+
Building
+
Building
+
+
+
+
BU.BuildingPart
+
BuildingPart
+
BuildingPart
+
+
+
+
+
+
NOTE Due to the lack of SLD for 3D data, the portrayal clause applies only for 2D core profile.
+
+
+
11.1.1. Layers organisation
+
+
None.
+
+
+
+
+
11.2. Styles required to be supported by INSPIRE view services
+
+
11.2.1. Styles for the layer BU.Building
+
+
+
+
+
+
+
+
Style Name
+
BU.Building.Default
+
+
+
+
+
Default Style
+
yes
+
+
+
Style Title
+
Building Default Style
+
+
+
Style Abstract
+
+
The building reference geometry is represented by following styles:
+
+
+
+
+
Style for surface geometries: grey with black outline
NOTE 1: The scale range enables the user to discover buildings from scale 1/ 25 000 but good rendering of buildings is generally obtained only at larger scales (≥ 1/10 000), especially in urban areas.
+
+
+
+
11.2.2. Styles for the layer BU.BuildingPart
+
+
+
+
+
+
+
+
Style Name
+
BU.BuildingPart.Default
+
+
+
+
+
Default Style
+
yes
+
+
+
Style Title
+
BuildingPart Default Style
+
+
+
Style Abstract
+
+
The building reference geometry is represented by following styles:
+
+
+
+
+
Style for surface geometries: hollow with black outline
Scale 1/500 ; BuildingPart combined with Building
+Building must be bottom layer
+BuildingPart must be top layer
+
+
+
+
+
+
Figure 77: 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.
+
+
+
+
+
11.3. Styles recommended to be supported by INSPIRE view services
+
+
None.
+
+
+
+
+
+
+
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
[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
+
+
+
OpenGIS® City Geography Markup Language (CityGML) Encoding Standard v2.0
+
+
+
+
+
+
Annex A: Abstract Test Suite -(normative)
+
+
+
+
+
+
+
+
+
Disclaimer
+
+
+
While this Annex refers to the Commission Regulation (EU) No 1089/2010 of 23 November 2010 implementing Directive 2007/2/EC of the European Parliament and of the Council as regards interoperability of spatial data sets and services, it does not replace the legal act or any part of it.
+
+
+
+
+
+
The objective of the Abstract Test Suite (ATS) included in this Annex is to help the conformance testing process. It includes a set of tests to be applied on a data set to evaluate whether it fulfils the requirements included in this data specification and the corresponding parts of Commission Regulation No 1089/2010 (implementing rule as regards interoperability of spatial datasets and services, further referred to as ISDSS Regulation). This is to help data providers in declaring the conformity of a data set to the "degree of conformity, with implementing rules adopted under Article 7(1) of Directive 2007/2/EC", which is required to be provided in the data set metadata according to Commission Regulation (EC) No 2008/1205 (the Metadata Regulation).
+
+
+
Part 1 of this ATS includes tests that provide input for assessing conformity with the ISDSS regulation. In order to make visible which requirements are addressed by a specific test, references to the corresponding articles of the legal act are given. The way how the cited requirements apply to bu specification is described under the testing method.
+
+
+
In addition to the requirements included in ISDSS Regulation this Technical guideline contains TG requirements too. TG requirements are technical provisions that need to be fulfilled in order to be conformant with the corresponding IR requirement when the specific technical implementation proposed in this document is used. Such requirements relate for example to the default encoding described in section 9. Part 2 of the ATS presents tests necessary for assessing the conformity with TG requirements.
+
+
+
NOTE Conformance of a data set with the TG requirement(s) included in this ATS implies conformance with the corresponding IR requirement(s).
+
+
+
The ATS is applicable to the data sets thathave been transformed to be made available through INSPIRE download services (i.e. the data returned as a response to the mandatory "Get Spatial Dataset" operation) rather than the original "source" data sets.
+
+
+
The requirements to be tested are grouped in several conformance classes. Each of these classes covers a specific aspect: one conformance class contains tests reflecting the requirements on the application schema, another on the reference systems, etc. Each conformance class is identified by a URI (uniform resource identifier) according to the following pattern:
The results of the tests should be published referring to the relevant conformance class (using its URI).
+
+
+
When an INSPIRE data specification contains more than one application schema, the requirements tested in a conformance class may differ depending on the application schema used as a target for the transformation of the data set. This will always be the case for the application schema conformance class. However, also other conformance classes could have different requirements for different application schemas. In such cases, a separate conformance class is defined for each application schema, and they are distinguished by specific URIs according to the following pattern:
An overview of the conformance classes and the associated tests is given in the table below.
+
+
+
+
+
+
+
+
A.1 Application Schema Conformance Class
+
+
+
+
+
+
+
+
+
A.1.1 Schema element denomination test
+
+
+
A.1.2 Value type test
+
+
+
A.1.3 Value test
+
+
+
A.1.4 Attributes/associations completeness test
+
+
+
A.1.5 Abstract spatial object test
+
+
+
A.1.6 Constraints test
+
+
+
A.1.7 Geometry representation test
+
+
+
+
+
+
A.2 Reference Systems Conformance Class
+
+
+
+
+
+
+
+
+
A.2.1 Datum test
+
+
+
A.2.2 Coordinate reference system test
+
+
+
A.2.3 View service coordinate reference system test
+
+
+
A.2.4 Temporal reference system test
+
+
+
A.2.5 Units of measurements test
+
+
+
+
+
+
A.3 Data Consistency Conformance Class
+
+
+
+
+
+
+
+
+
A.3.1 Unique identifier persistency test
+
+
+
A.3.2 Version consistency test
+
+
+
A.3.3 Life cycle time sequence test
+
+
+
A.3.4 Update frequency test
+
+
+
+
+
+
A.4 Metadata IR Conformance Class
+
+
+
+
+
+
+
+
+
A.4.1 Metadata for interoperability test
+
+
+
+
+
+
A.5 Information Accessibility Conformance Class
+
+
+
+
+
+
+
+
+
A.5.1 Code list publication test
+
+
+
A.5.2 CRS publication test
+
+
+
A.5.3 CRS identification test
+
+
+
+
+
+
A.6 Data Delivery Conformance Class
+
+
+
+
+
+
+
+
+
A.6.1 Encoding compliance test
+
+
+
+
+
+
A.7 Portrayal Conformance Class
+
+
+
+
+
+
+
+
+
A.7.1 Layer designation test
+
+
+
+
+
+
A.8 Technical Guideline Conformance Class
+
+
+
+
+
+
+
+
+
A.8.1 Multiplicity test
+
+
+
A.8.2 CRS http URI test
+
+
+
A.8.3 Metadata encoding schema validation test
+
+
+
A.8.4 Metadata occurrence test
+
+
+
A.8.5 Metadata consistency test
+
+
+
A.8.6 Encoding schema validation test
+
+
+
A.8.7 Style test
+
+
+
+
+
+
+
+
In order to be conformant to a conformance class, a data set has to pass all tests defined for that conformance class.
+
+
+
In order to be conformant with the ISDSS regulation the inspected data set needs to be conformant to all conformance classes in Part 1. The conformance class for overall conformity with the ISDSS regulation is identified by the URI http://inspire.ec.europa.eu/conformance-class/ir/bu/.
+
+
+
In order to be conformant with the Technical Guidelines, the dataset under inspection needs to be conformant to all conformance classes included both in Part 1 and 2. Chapter 8 describes in detail how to publish the result of testing regarding overall conformity and conformity with the conformance classes as metadata. The conformance class for overall conformity with the Technical Guidelines is identified by the URI http://inspire.ec.europa.eu/conformance-class/tg/bu/3.0.
+
+
+
It should be noted that data providers are not obliged to integrate / decompose the original structure of the source data sets when they deliver them for INSPIRE. It means that a conformant dataset can contain less or more spatial object / data types than specified in the ISDSS Regulation.
+
+
+
A dataset that contains less spatial object and/or data types can be regarded conformant when the corresponding types of the source datasets after the necessary transformations fulfil the requirements set out in the ISDSS Regulation.
+
+
+
A dataset that contain more spatial object and/or data types may be regarded as conformant when
+
+
+
+
+
all the spatial object / data types that have corresponding types in the source dataset after the necessary transformations fulfil the requirements set out in the ISDSS Regulation and
+
+
+
all additional elements of the source model (spatial object types, data types, attributes, constraints and code lists together with their values) do not conflict with any rule defined in the interoperability target specifications defined for any theme within INSPIRE.
+
+
+
+
+
+
+
Open issue 2: Even though the last condition can be derived from Art. 8(4) of the Directive, the ISDSS Regulation does not contain requirements concerning the above issue. Therefore, no specific tests have been included in this abstract suit for testing conformity of extended application schemas. Annex F of the Generic Conceptual Model (D2.5) provides an example how to extend INSPIRE application schemas in a compliant way.
+
+
+
+
+
The ATS contains a detailed list of abstract tests. It should be noted that some tests in the Application schema conformance class can be automated by utilising xml schema validation tools. It should be noted that failing such validation test does not necessary reflect non-compliance to the application schema; it may be the results of erroneous encoding.
+
+
+
Each test in this suit follows the same structure:
+
+
+
+
+
Requirement: citation from the legal texts (ISDSS requirements) or the Technical Guidelines (TG requirements);
+
+
+
Purpose: definition of the scope of the test;
+
+
+
Reference: link to any material that may be useful during the test;
+
+
+
Test method: description of the testing procedure.
+
+
+
+
+
According to ISO 19105:2000 all tests in this ATS are basic tests. Therefore, this statement is not repeated each time.
+
+
Part 1 - (normative)
+
+
Conformity with Commission Regulation No 1089/2010
Purpose: Verification whether each element of the dataset under inspection carries a name specified in the target application schema(s).
+
+
+
Reference: Art. 3 and Art.4 of Commission Regulation No 1089/2010
+
+
+
Test Method: Examine whether the corresponding elements of the source schema (spatial object types, data types, attributes, association roles and code lists) are mapped to the target schema with the correct designation of mnemonic names.
+
+
+
+
+
NOTE Further technical information is in the Feature catalogue and UML diagram of the application schema(s) in sections 5.2, 5.3 and 5.4.
+
+
+
+
A.1.2. Value type test
+
+
+
+
Purpose: Verification whether all attributes or association roles use the corresponding value types specified in the application schema(s).
+
+
+
Reference: Art. 3, Art.4, Art.6(1), Art.6(4), Art.6(5) and Art.9(1)of Commission Regulation No 1089/2010.
+
+
+
Test Method: Examine whether the value type of each provided attribute or association role adheres to the corresponding value type specified in the target specification.
+
+
+
+
+
NOTE 1 This test comprises testing the value types of INSPIRE identifiers, the value types of attributes and association roles that should be taken from code lists, and the coverage domains.
+
+
+
NOTE 2 Further technical information is in the Feature catalogue and UML diagram of the application schema(s) in sections 5.2, 5.3 and 5.4.
+
+
+
+
A.1.3. Value test
+
+
+
+
Purpose: Verify whether all attributes or association roles whose value type is a code list take the values set out therein.
+
+
+
Reference: Art.4 (3) of Commission Regulation No 1089/2010.
+
+
+
Test Method: When an attributes / association roles has "codeList" type compare the values of each instance with those provided in the application schema. To pass this tests any instance of an attribute / association role
+
+
+
+
Shall take only values explicitly specified in the code list when its type is codeList with extensibility value is "none".
+
+
+
Shall take only a value explicitly specified in the code list or shall take a value that is narrower (i.e. more specific) than those explicitly specified in the application schema when the type is codeList with extensibility value is "narrower".
+
+
+
+
+
+
+
+
NOTE 1 This test is not applicable to code lists with extensibility "any".
+
+
+
NOTE 2 When a data provider only uses code lists with narrower (more specific values) this test can be fully performed based on internal information.
+
+
+
+
A.1.4. Attributes/associations completeness test
+
+
+
+
Purpose: Verification whether each instance of spatial object type and data types include all attributes and association roles as defined in the target application schema.
+
+
+
Reference: Art. 3, Art.4(1), Art.4(2), and Art.5(2) of Commission Regulation No 1089/2010.
+
+
+
Test Method: Examine whether all attributes and association roles defined for a spatial object type or data type are present for each instance in the dataset.
+
+
+
+
+
NOTE 1 Further technical information is in the Feature catalogue and UML diagram of the application schema(s) in sections 5.2, 5.3 and 5.4.
+
+
+
NOTE 2 If an attribute has the stereotype «voidable», then according to the INSPIRE Generic Conceptual Model (section 9.8.4.3) one of the three "void reason" values "unknown", "unpopulated" or "withheld" shall be provided instead of the real values.
+
+
+
NOTE 3 If the characteristic described by the attribute or association role does not apply to the real world entity, the attribute or association role does not need to be present in the data set.
+
+
+
+
A.1.5. Abstract spatial object test
+
+
+
+
Purpose: Verification whether the dataset does NOT contain abstract spatial object / data types defined in the target application schema(s).
+
+
+
Reference: Art.5(3) of Commission Regulation No 1089/2010
+
+
+
Test Method: examine that there are NO instances of abstract spatial object / data types in the dataset provided.
+
+
+
+
+
NOTE Further technical information is in the Feature catalogue and UML diagram of the application schema(s) in sections 5.2, 5.3 and 5.4.
+
+
+
+
A.1.6. Constraints test
+
+
+
+
Purpose: Verification whether the instances of spatial object and/or data types provided in the dataset adhere to the constraints specified in the target application schema(s).
+
+
+
Reference: Art. 3, Art.4(1), and Art.4(2) of Commission Regulation No 1089/2010.
+
+
+
Test Method: Examine all instances of data for the constraints specified for the corresponding spatial object / data type. Each instance shall adhere to all constraints specified in the target application schema(s).
+
+
+
+
+
NOTE Further technical information is in the Feature catalogue and UML diagram of the application schema(s) in sections 5.2, 5.3 and 5.4.
+
+
+
+
A.1.7. Geometry representation test
+
+
+
+
Purpose: Verification whether the value domain of spatial properties is restricted as specified in the Commission Regulation No 1089/2010.
+
+
+
Reference: Art.12(1), Annex IV Section 2 of Commission Regulation No 1089/2010
+
+
+
Test Method: Check whether all spatial properties only use 0, 1 and 2-dimensional geometric objects that exist in the right 2-, 3- or 4-dimensional coordinate space, and where all curve interpolations respect the rules specified in the reference documents.
+
+
+
+
+
NOTE 1 Further technical information is in OGC Simple Feature spatial schema v1.2.1 [06-103r4].
+
+
+
NOTE 2 This test does not apply for the 3D application schema since the OGC Simple Feature spatial schema is not relevant.
Purpose: Verify whether each instance of a spatial object type is given with reference to one of the (geodetic) datums specified in the target specification.
+
+
+
Reference: Annex II Section 1.2 of Commission Regulation No 1089/2010
+
+
+
Test Method: Check whether each instance of a spatial object type specified in the application schema(s) in section 5 has been expressed using:
+
+
+
+
the European Terrestrial Reference System 1989 (ETRS89) within its geographical scope; or
+
+
+
the International Terrestrial Reference System (ITRS) for areas beyond the ETRS89 geographical scope; or
+
+
+
other geodetic coordinate reference systems compliant with the ITRS. Compliant with the ITRS means that the system definition is based on the definition of ITRS and there is a well-established and described relationship between both systems, according to the EN ISO 19111.
+
+
+
+
+
+
+
+
NOTE Further technical information is given in Section 6 of this document.
+
+
+
+
A.2.2. Coordinate reference system test
+
+
+
+
Purpose: Verify whether the two- and three-dimensional coordinate reference systems are used as defined in section 6.
+
+
+
Reference: Section 6 of Commission Regulation 1089/2010.
+
+
+
Test Method: Inspect whether the horizontal and vertical components of coordinates one of the corresponding coordinate reference system has been:
+
+
+
+
Three-dimensional Cartesian coordinates based on a datum specified in 1.2 and using the parameters of the Geodetic Reference System 1980 (GRS80) ellipsoid.
+
+
+
Three-dimensional geodetic coordinates (latitude, longitude and ellipsoidal height) based on a datum specified in 1.2 and using the parameters of the GRS80 ellipsoid.
+
+
+
Two-dimensional geodetic coordinates (latitude and longitude) based on a datum specified in 1.2 and using the parameters of the GRS80 ellipsoid.
+
+
+
Plane coordinates using the ETRS89 Lambert Azimuthal Equal Area coordinate reference system.
+
+
+
Plane coordinates using the ETRS89 Lambert Conformal Conic coordinate reference system.
+
+
+
Plane coordinates using the ETRS89 Transverse Mercator coordinate reference system.
+
+
+
For the vertical component on land, the European Vertical Reference System (EVRS) shall be used to express gravity-related heights within its geographical scope. Other vertical reference systems related to the Earth gravity field shall be used to express gravity-related heights in areas that are outside the geographical scope of EVRS.
+
+
+
For the vertical component in marine areas where there is an appreciable tidal range (tidal waters), the Lowest Astronomical Tide (LAT) shall be used as the reference surface.
+
+
+
For the vertical component in marine areas without an appreciable tidal range, in open oceans and effectively in waters that are deeper than 200 meters, the Mean Sea Level (MSL) or a well-defined reference level close to the MSL shall be used as the reference surface."
+
+
+
For the vertical component in the free atmosphere, barometric pressure, converted to height using ISO 2533:1975 International Standard Atmosphere, or other linear or parametric reference systems shall be used. Where other parametric reference systems are used, these shall be described in an accessible reference using EN ISO 19111-2:2012.
+
+
+
+
+
+
+
+
NOTE Further technical information is given in Section 6 of this document.
+
+
+
+
A.2.3. View service coordinate reference system test
+
+
+
+
Purpose: Verify whether the spatial data set is available in the two dimensional geodetic coordinate system for their display with the INSPIRE View Service.
+
+
+
Reference: Annex II Section 1.4 of Commission Regulation 1089/2010
+
+
+
Test Method: Check that each instance of a spatial object types specified in the application schema(s) in section 5 is available in the two-dimensional geodetic coordinate system
+
+
+
+
+
NOTE Further technical information is given in Section 6 of this document.
+
+
+
+
A.2.4. Temporal reference system test
+
+
+
+
Purpose: Verify whether date and time values are given as specified in Commission Regulation No 1089/2010.
+
+
+
Reference: Art.11(1) of Commission Regulation 1089/2010
+
+
+
Test Method: Check whether:
+
+
+
+
the Gregorian calendar is used as a reference system for date values;
+
+
+
the Universal Time Coordinated (UTC) or the local time including the time zone as an offset from UTC are used as a reference system for time values.
+
+
+
+
+
+
+
+
NOTE Further technical information is given in Section 6 of this document.
+
+
+
+
A.2.5. Units of measurements test
+
+
+
+
Purpose: Verify whether all measurements are expressed as specified in Commission Regulation No 1089/2010.
+
+
+
Reference: Art.12(2) of Commission Regulation 1089/2010
+
+
+
Test Method: Check whether all measurements are expressed in SI units or non-SI units accepted for use with the International System of Units.
+
+
+
+
+
NOTE 1 Further technical information is given in ISO 80000-1:2009.
+
+
+
NOTE 2 Degrees, minutes and seconds are non-SI units accepted for use with the International System of Units for expressing measurements of angles.
Purpose: Verify whether the namespace and localId attributes of the external object identifier remain the same for different versions of a spatial object.
+
+
+
Reference: Art. 9 of Commission Regulation 1089/2010.
+
+
+
Test Method: Compare the namespace and localId attributes of the external object identifiers in the previous version(s) of the dataset with the namespace and localId attributes of the external object identifiers of current version for the same instances of spatial object / data types; To pass the test, neither the namespace, nor the localId shall be changed during the life-cycle of a spatial object.
+
+
+
+
+
NOTE 1 The localId test can be performed entirely on the basis of the information available in the database of the data providers.
+
+
+
NOTE 2 When using URI this test includes the verification whether no part of the construct has been changed during the life cycle of the instances of spatial object / data types.
+
+
+
NOTE 3 Further technical information is given in section 14.2 of the INSPIRE Generic Conceptual Model.
+
+
+
+
A.3.2. Version consistency test
+
+
+
+
Purpose: Verify whether different versions of the same spatial object / data type instance belong to the same type.
+
+
+
Reference: Art. 9 of Commission Regulation 1089/2010.
+
+
+
Test Method: Compare the types of different versions for each instance of spatial object / data type
+
+
+
+
+
NOTE 1 This can be performed entirely on the basis of the information available in the database of the data providers.
+
+
+
+
A.3.3. Life cycle time sequence test
+
+
+
+
Purpose: Verification whether the value of the attribute beginLifespanVersion refers to an earlier moment of time than the value of the attribute endLifespanVersion for every spatial object / object type where this property is specified.
+
+
+
Reference: Art.10(3) of Commission Regulation 1089/2010.
+
+
+
Test Method: Compare the value of the attribute beginLifespanVersion with attribute endLifespanVersion. The test is passed when the beginLifespanVersion value is before endLifespanVersion value for each instance of all spatial object/data types for which this attribute has been defined.
+
+
+
+
+
NOTE 1 this test can be performed entirely on the basis of the information available in the database of the data providers.
+
+
+
+
A.3.4. Update frequency test
+
+
+
+
Purpose: Verify whether all the updates in the source dataset(s) have been transmitted to the dataset(s) which can be retrieved for the bu using INSPIRE download services.
+
+
+
Reference: Art.8 (2) of Commission Regulation 1089/2010.
+
+
+
Test Method: Compare the values of beginning of life cycle information in the source and the target datasets for each instance of corresponding spatial object / object types. The test is passed when the difference between the corresponding values is less than 6 months.
+
+
+
+
+
NOTE 1 this test can be performed entirely on the basis of the information available in the database of the data providers.
Purpose: Verify whether the metadata for interoperability of spatial data sets and services described in 1089/2010 Commission Regulation have been created and published for each dataset related to the BU data theme.
+
+
+
Reference: Art.13 of Commission Regulation 1089/2010
+
+
+
Test Method: Inspect whether metadata describing the coordinate reference systems, temporal reference system, encoding, character encoding and when applicable topological consistency have been created and published.
+
+
+
+
+
NOTE Further technical information is given in section 8 of this document.
Purpose: Verify whether the values of each code list that allow narrower values or any other value than specified in Commission Regulation 1089/2010 are published in a register.
+
+
+
Reference: Art.6(3)
+
+
+
Reference: Art.6(3) and Annex IV Section 2.
+
+
+
+
+
NOTE Further technical information is given in section 5 of this document.
+
+
+
+
A.5.2. CRS publication test
+
+
+
+
Purpose: Verify whether the identifiers and the parameters of coordinate reference system are published in common registers.
+
+
+
Reference: Annex II Section 1.5
+
+
+
Test Method: Check whether the identifier and the parameter of the CRS used for the dataset are included in a register. .
+
+
+
+
+
NOTE Further technical information is given in section 6 of this document.
+
+
+
+
A.5.3. CRS identification test
+
+
+
+
Purpose: Verify whether identifiers for other coordinate reference systems than specified in Commission Regulation 1089/2010 have been created and their parameters have been described according to EN ISO 19111 and ISO 19127.
+
+
+
Reference: Annex II Section 1.3.4
+
+
+
Test Method: Check whether the register with the identifiers of the coordinate reference systems is accessible.
+
+
+
+
+
NOTE Further technical information is given in section 6 of this document.
Purpose: Verify whether each instance of an attribute or association role specified in the application schema(s) does not include fewer or more occurrences than specified in section 5.
+
+
+
Reference: Feature catalogue and UML diagram of the application schema(s) in section 5 of this guideline.
+
+
+
Test Method: Examine that the number of occurrences of each attribute and/or association role for each instance of a spatial object type or data type provided in the dataset corresponds to the number of occurrences of the attribute / association role that is specified in the application schema(s) in section 5.
+
+
+
+
+
+
A.8.2. CRS http URI test
+
+
+
+
Purpose: Verify whether the coordinate reference system used to deliver data for INSPIRE network services has been identified by URIs according to the EPSG register.
+
+
+
Reference: Section 6 of this technical guideline
+
+
+
Test Method: Compare the URI of the dataset with the URIs in the table.
+
+
+
+
+
NOTE 1 Passing this test implies the fulfilment of test A6.2
Purpose: Verify whether the metadata follows an XML schema specified in ISO/TS 19139.
+
+
+
Reference: Section 8 of this technical guideline, ISO/TS 19139
+
+
+
Test Method: Inspect whether provided XML schema is conformant to the encoding specified in ISO 19139 for each metadata instance.
+
+
+
+
+
NOTE 1 Section 2.1.2 of the Metadata Technical Guidelines discusses the different ISO 19139 XML schemas that are currently available.
+
+
+
+
A.8.4. Metadata occurrence test
+
+
+
+
Purpose: Verify whether the occurrence of each metadata element corresponds to those specified in section 8.
+
+
+
Reference: Section 8 of this technical guideline
+
+
+
Test Method: Examine the number of occurrences for each metadata element. The number of occurrences shall be compared with its occurrence specified in Section 8:
+
+
+
+
+
NOTE 1 Section 2.1.2 of the Metadata Technical Guidelines discusses the different ISO 19139 XML schema.
+
+
+
+
A.8.5. Metadata consistency test
+
+
+
+
Purpose: Verify whether the metadata elements follow the path specified in ISO/TS 19139.
+
+
+
Reference: Section 8 of this technical guideline, ISO/TS 19139
+
+
+
Test Method: Compare the XML schema of each metadata element with the path provide in ISO/TS 19137.
+
+
+
+
+
NOTE 1 This test does not apply to the metadata elements that are not included in ISO/TS 19139.
+
+
+
+
A.8.6. Encoding schema validation test
+
+
+
+
Purpose: Verify whether the provided dataset follows the rules of default encoding specified in section 9 of this document
+
+
+
Reference: section 9 of this technical guideline
+
+
+
Test Method: Inspect whether provided encoding(s) is conformant to the encoding(s) for the relevant application schema(s) as defined in section 9:
+
+
+
+
+
NOTE 1 Applying this test to the default encoding schema described in section 9 facilitates testing conformity with the application schema specified in section 5. In such cases running this test with positive result may replace tests from A1.1 to A1.4 provided in this abstract test suite.
+
+
+
NOTE 2 Using Schematron or other schema validation tool may significantly improve the validation process, because some some complex constraints of the schema cannot be validated using the simple XSD validation process. On the contrary to XSDs Schematron rules are not delivered together with the INSPIRE data specifications. Automating the process of validation (e.g. creation of Schematron rules) is therefore a task and an opportunity for data providers.
+
+
+
+
A.8.7. Style test
+
+
+
+
Purpose: Verify whether the styles defined in section 11.2 have been made available for each specified layer.
+
+
+
Reference: section 11.2.
+
+
+
Test Method: Check whether the styles defined in section 11.2 have been made available for each specified layer.
+
+
+
+
+
+
+
+
+
+
Annex B: Use cases - (informative)
+
+
+
Table of content
+
+
+
+
+
+
+
+
B.1 Common use of building data
+
+
+
+
+
+
+
+
+
B.1.1 Modelling of physical phenomena
+
+
+
B.1.2 Computation of population in an area of interest
+
+
+
B.1.3 Large scale 2D mapping
+
+
+
B.1.4 Deriving medium scale data
+
+
+
B.1.5 3D models
+
+
+
+
+
+
B.2 Safety
+
+
+
+
+
+
+
+
+
B.2.1 Travel security
+
+
+
B.2.2 Risk assessment
+
+
+
B.2.3 Risk management
+
+
+
+
+
+
B.3 Urban expansion
+
+
+
+
+
+
+
+
+
B.3.1 Integrated urban monitoring
+
+
+
B.3.2 Urban planning
+
+
+
B.3.3 Urban monitoring
+
+
+
+
+
+
B.4 Environment
+
+
+
+
+
+
+
+
+
B.4.1 Noise
+
+
+
B.4.2 Air quality
+
+
+
B.4.3 Soil
+
+
+
B.4.4 Energy / Sustainable buildings
+
+
+
B.4.5 Quality of habitat
+
+
+
B.4.6 Buildings with historical or architectural interest
+
+
+
+
+
+
B.5 Infrastructures
+
+
+
+
+
+
+
+
+
B.5.1 Location of a new service/activity
+
+
+
B.5.2 Management of service/activity
+
+
+
B.5.3 Management / valorisation of public patrimony
+
+
+
+
+
+
B.6 Census
+
+
+
+
+
+
+
+
+
B.6.1 European Census
+
+
+
B.6.2 Census Units
+
+
+
+
+
+
+
+
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.
+
+
+
B.1. Common use of building data
+
+
B.1.1. Modelling of physical phenomena
+
+
Part 1: UML use case diagram
+
+
+
+
+
+
+
+
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.
+
+
+
+
+
+
+
+
Principle of propagation model
+
+
+
+
+
+
+
+
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
+
+
+
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.
+
+
+
+
+
+
+
B.1.2. Computation of population in an area of interest
+
+
Part 1: UML use case diagram
+
+
+
+
+
+
+
+
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
+
+
+
Principle of computation of population in an area of interest
+
+
+
+
+
Part 3: Detailed, structured description of the use case
+
+
+
Assessment of population at night
+
+
+
+
+
+
+
+
+
Use Case Description
+
+
+
+
+
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.
+
+
+
Flow of Events – Basic Path
+
+
+
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.
+
+
+
Flow of Events – Alternative Paths
+
+
+
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
+
+
+
+
+
Assessing population at day
+
+
+
+
+
+
+
+
+
Use Case Description
+
+
+
+
+
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.
+
+
+
Flow of Events – Basic Path
+
+
+
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.
+
+
+
+
Flow of Events – Alternative Paths
+
+
+
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).
+
+
+
Data source: <Name> [repeat per data source]
+
+
+
Description
+
INSPIRE themes SU, US, PF, PD, BU, AD
+
+
+
Geographic scope
+
Area of interest, anywhere in Europe
+
+
+
+
+
+
B.1.3. Large scale 2D mapping
+
+
Part 1: UML use case diagram
+
+
+
+
+
+
+
+
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
+
+
+
+
+
+
Flow of Events – Basic Path
+
+
+
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.
+
+
+
Data source: <Name> [repeat per data source]
+
+
+
Description
+
INSPIRE themes at least TN, BU, US and possibly AU, CP, AD, HY, GN
+
+
+
Geographic scope
+
Urban areas, everywhere in Europe
+
+
+
+
+
+
B.1.4. Deriving medium scale data
+
+
Part 1: UML use case diagram
+
+
+
+
+
+
+
+
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
+
+
+
+
+
+
+
+
+
Example: Swiss topo maps
+
+
+
+
+
Part 3: Detailed, structured description of the use case
+
+
+
+
+
+
+
+
+
Use Case Description
+
+
+
+
+
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.
+
+
+
+
Flow of Events – Basic Path
+
+
+
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.
+
+
+
Flow of Events – Alternative Paths
+
+
+
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.
+
+
+
Data source: <Name> [repeat per data source]
+
+
+
Description
+
INSPIRE themes BU, US, TN, HY (and possibly OI)
+
+
+
Geographic scope
+
Any urban area in Europe
+
+
+
+
+
+
B.1.5. 3D models
+
+
Part 1: UML use case diagram
+
+
+
+
+
+
+
+
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.
+
+
+
+
+
+
+
+
+
+
Project of a new motorway and new neighbourhoods
+
+
+
Part 3: Detailed, structured description of the use case
+
+
+
+
+
+
+
+
+
Use Case Description
+
+
+
+
+
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
+
+
+
+
Flow of Events – Basic Path
+
+
+
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.
+
+
+
Flow of Events – Alternative Paths
+
+
+
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.
+
+
+
+
+
+
+
+
B.2. Safety
+
+
B.2.1. Travel security
+
+
Part 1: UML use case diagram
+
+
+
+
+
+
+
+
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
+
+
+
Marine charts
+
+
+
+
+
Part 3:Detailed, structured description of the use case
+
+
+
+
+
+
+
+
+
Use Case Description
+
+
+
+
+
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.
+
+
+
Flow of Events – Basic Path
+
+
+
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 redefined 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.
+
+
+
+
Flow of Events – Alternative Paths
+
+
+
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.
+
+
+
Data source: <Name> [repeat per data source]
+
+
+
Description
+
INSPIRE themes BU, US
+
+
+
Geographic scope
+
Along sea coastlines
+
+
+
+
+
+
B.2.2. Risk assessment
+
+
Part 1: UML use case diagram
+
+
+
+
+
+
+
+
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.
+
+
+
Earthquake is potentially the most significant hazard as it may cause thousands of death. Some parts of Europe are subject to earthquakes.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Assessment of earthquake risk
+
+
+
+
+
+
+
In opposite to other continents, Europe is not frequently victim of wind storms. However, this hazard 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
+
+
+
+
+
+
+
+
+
Use Case Description
+
+
+
+
+
Name
+
Assessment of risk
+
+
+
Priority
+
high
+
+
+
Description
+
The purpose is to estimate the impact of a potential risk
+
+
+
Pre-condition
+
The hazard zone has been delimited. In case of natural hazards, theme NZ is available.
+
+
+
Flow of Events – Basic Path
+
+
+
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 hazard area.
+
+
+
Step 3
+
+
Assess the general vulnerability of the hazard area. Typically, identify if infrastructures that are essential for the community (such as water / power / telecommunication supply,hospitals, rescue services) are in the hazard area.
+
+
+
This may be done using attribute service type of governmental services.
+
+
+
+
Step 4
+
+
In the hazard area, assess the vulnerability of the buildings, e.g. using attributes:
+
+
+
+
+
material of structure for fire or earthquake
+
+
+
number of floors, floor description (with area of openings) for flood and earthquake
+
+
+
material of façade, material of structure for industrial hazard
+
+
+
+
+
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 hazard area, 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 hazard area, 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.
+
+
+
+
Flow of Events – Alternative Paths
+
+
+
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 risk is assessed and may be reported, if required by a European Directive (e.g. Flood Directive)
+
+
+
Data source: <Name> [repeat per data source]
+
+
+
Description
+
INSPIRE themes BU, US, PF, AF, TN ….
+
+
+
Geographic scope
+
Risk areas in Europe
+
+
+
+
+
+
B.2.3. Risk management
+
+
Part 1: UML use case diagram
+
+
+
+
+
+
+
+
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 hazard occurs.
+
+
+
+
+
+
+
+
Buildings in a flooded area
+
+
+
Part 3: Detailed, structured description of the use case
+
+
+
+
+
+
+
+
+
Use Case Description
+
+
+
+
+
Name
+
Management of risk
+
+
+
Priority
+
high
+
+
+
Description
+
The purpose is to manage the hazard, in order to decrease its consequences.
+
+
+
Pre-condition
+
The hazard has been (more or less) identified, delimited and assessed
+
+
+
Flow of Events – Basic Path
+
+
+
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 hazard. 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 hazard 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 hazard (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 hazard areas. Identify key infrastructures, such as bridges and tunnels, check how they may be affected by the hazard, 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 hazard, 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 hazard is managed and its consequences are reduced, as much as possible.
+
+
+
Data source: <Name> [repeat per data source]
+
+
+
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.
+
+
+
+
+
B.3. Urban expansion
+
+
B.3.1. Integrated urban monitoring
+
+
Part 1: UML use case diagram
+
+
+
+
+
+
+
+
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.
+
+
+
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.
+
+
+
+
+
+
+
+
Urban Atlas Madrid
+
+
+
Part 3: Detailed, structured description of the use case
+
+
+
+
+
+
+
+
+
Use Case Description
+
+
+
+
+
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.
+
+
+
Flow of Events – Basic Path
+
+
+
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
+
+
+
Data source: <Name> [repeat per data source]
+
+
+
Description
+
INSPIRE themes BU, US, TN, HY (and possibly OI)
+
+
+
Geographic scope
+
Any urban area in Europe
+
+
+
+
+
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.
+
+
+
+
+
+
+
+
Principles of INSPIRE land use classification
+
+
+
Part 3: Detailed, structured description of the use case
+
+
+
+
+
+
+
+
+
Use Case Description
+
+
+
+
+
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.
+
+
+
Flow of Events – Basic Path
+
+
+
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.
+
+
+
Data source: <Name> [repeat per data source]
+
+
+
Description
+
INSPIRE themes BU, US, TN, HY (and possibly OI)
+
+
+
Geographic scope
+
Any urban area in Europe
+
+
+
+
+
Urban metabolism
+
+
+
Some of the indicators used to monitor the urban metabolism are related to land use and to buildings
+
+
+
+
+
+
+
+
A pragmatic indicator framework for quantifying urban metabolism.
+
+
+
Part 3: Detailed, structured description of the use case
+
+
+
+
+
+
+
+
+
Use Case Description
+
+
+
+
+
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.
+
+
+
Flow of Events – Basic Path
+
+
+
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
+
+
+
Data source: <Name> [repeat per data source]
+
+
+
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).
+
+
+
+
B.3.2. Urban planning
+
+
Part 1: UML use case diagram
+
+
+
+
+
+
+
+
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.
Part 3: Detailed, structured description of the use case
+
+
+
+
+
+
+
+
+
Use Case Description
+
+
+
+
+
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.
+
+
+
+
Flow of Events – Basic Path
+
+
+
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
+
+
+
Data source: <Name> [repeat per data source]
+
+
+
Description
+
INSPIRE themes BU, US, PF, AF, TN, CP
+
+
+
Geographic scope
+
Any urban area in Europe
+
+
+
+
+
+
B.3.3. Urban monitoring
+
+
Part 1: UML use case diagram
+
+
+
+
+
+
+
+
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.
+
+
+
+
+
+
+
+
Detailed cadastral data for urban monitoring
+
+
+
Part 3: Detailed, structured description of the use case
+
+
+
+
+
+
+
+
+
Use Case Description
+
+
+
+
+
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.
+
+
+
+
Flow of Events – Basic Path
+
+
+
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.
+
+
+
+
Flow of Events – Alternative Paths
+
+
+
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.
+
+
+
Data source: <Name> [repeat per data source]
+
+
+
Description
+
INSPIRE themes BU, TN, CP
+
+
+
Geographic scope
+
Any urban area in Europe
+
+
+
+
+
+
+
B.4. Environment
+
+
B.4.1. Noise
+
+
Part 1: UML use case diagram
+
+
+
+
+
+
+
+
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.
+
+
+
+
+
+
+
+
Extract of a noise map around an airport
+
+
+
Part 3:Detailed, structured description of the use case
+
+
+
+
+
+
+
+
+
Use Case Description
+
+
+
+
+
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
+
+
+
Flow of Events – Basic Path
+
+
+
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.
+
+
+
Data source: <Name> [repeat per data source]
+
+
+
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
+
+
+
+
B.4.2. Air quality
+
+
Part 2: Narrative explanation of the use case
+
+
+
The European legislation (newDirective 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.
+
+
+
+
+
+
+
+
+
+
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
+
+
+
+
B.4.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.
+
+
+
+
+
+
+
+
+
+
Soil contamination
+
+
+
Part 3: Detailed, structured description of the use case
+
+
+
+
+
+
+
+
+
Use Case Description
+
+
+
+
+
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
+
+
+
Flow of Events – Basic Path
+
+
+
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
+
+
+
Data source: <Name> [repeat per data source]
+
+
+
Description
+
INSPIRE themes BU, PF, SO, CP, AD
+
+
+
Geographic scope
+
Everywhere in Europe
+
+
+
+
+
+
B.4.4. Energy / Sustainable buildings
+
+
Part 1: UML use case diagram
+
+
+
+
+
+
+
+
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.
+
+
+
+
+
+
+
+
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.
+
+
+
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
+
+
+
Flow of Events – Basic Path
+
+
+
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.
+
+
+
Data source: <Name> [repeat per data source]
+
+
+
Description
+
INSPIRE themes BU, PF, SO, CP, AD
+
+
+
Geographic scope
+
Everywhere in Europe
+
+
+
+
+
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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
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.
+
+
+
Flow of Events – Basic Path
+
+
+
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.
+
+
+
Data source: <Name> [repeat per data source]
+
+
+
Description
+
INSPIRE themes BU
+
+
+
Geographic scope
+
Everywhere in Europe
+
+
+
+
+
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
+
+
+
+
+
+
+
+
+
Use Case Description
+
+
+
+
+
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.
+
+
+
Flow of Events – Basic Path
+
+
+
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.
+
+
+
Data source: <Name> [repeat per data source]
+
+
+
Description
+
INSPIRE themes BU, EL, possibly OI
+
+
+
Geographic scope
+
Sunny areas in Europe
+
+
+
+
+
+
B.4.5. Quality of habitat
+
+
Part 1: UML use case diagram
+
+
+
+
+
+
+
+
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.
+
+
+
+
+
+
+
+
Simulation of project, buildings that are going to be demolished are shown in blue
+
+
+
Part 3: Detailed, structured description of the use case
+
+
+
+
+
+
+
+
+
Use Case Description
+
+
+
+
+
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.
+
+
+
Flow of Events – Basic Path
+
+
+
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.
+
+
+
Data source: <Name> [repeat per data source]
+
+
+
Description
+
INSPIRE themes BU, US, TN, CP
+
+
+
Geographic scope
+
Everywhere in Europe
+
+
+
+
+
+
B.4.6. Buildings with historical or architectural interest
+
+
Part 1: UML use case diagram
+
+
+
+
+
+
+
+
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.
+
+
+
+
+
+
+
+
Mont Saint-Michel (France)
+
+
+
Part 3: Detailed, structured description of the use case
+
+
+
+
+
+
+
+
+
Use Case Description
+
+
+
+
+
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.
+
+
+
Pre-condition
+
Building data is available
+
+
+
Flow of Events – Basic Path
+
+
+
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
+
+
+
Data source: <Name> [repeat per data source]
+
+
+
Description
+
INSPIRE themes BU, US, PF, TN, CP
+
+
+
Geographic scope
+
Everywhere in Europe
+
+
+
+
+
+
+
B.5. Infrastructures
+
+
Part 1: UML use case diagram
+
+
+
+
+
+
+
+
Use case diagram for Infrastructure implementation and management
+
+
+
B.5.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
+
+
+
+
+
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
+
+
+
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
+
+
+
+
+
+
+
+
+
Use Case Description
+
+
+
+
+
Name
+
Location of a new wind farm
+
+
+
Priority
+
high
+
+
+
Description
+
The purpose is to identify the potential location of new wind farms.
+
+
+
Pre-condition
+
+
+
+
Flow of Events – Basic Path
+
+
+
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.
+
+
+
Data source: <Name> [repeat per data source]
+
+
+
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.
+
+
+
+
+
+
+
+
+
Use Case Description
+
+
+
+
+
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
+
+
+
Flow of Events – Basic Path
+
+
+
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.
+
+
+
Data source: <Name> [repeat per data source]
+
+
+
Description
+
INSPIRE themes BU
+
+
+
Geographic scope
+
Anywhere in Europe
+
+
+
+
+
+
B.5.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.
+
+
+
+
+
+
+
+
+
Use Case Description
+
+
+
+
+
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.
+
+
+
Flow of Events – Basic Path
+
+
+
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.
+
+
+
Data source: <Name> [repeat per data source]
+
+
+
Description
+
INSPIRE themes BU, SU, PD
+
+
+
Geographic scope
+
Anywhere in Europe
+
+
+
+
+
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.
+
+
+
+
+
+
+
+
+
Use Case Description
+
+
+
+
+
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
+
+
+
+
Flow of Events – Basic Path
+
+
+
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..
+
+
+
Data source: <Name> [repeat per data source]
+
+
+
Description
+
INSPIRE themes BU, US, PF, TN, AD, ..
+
+
+
Geographic scope
+
Anywhere in Europe
+
+
+
+
+
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.
+
+
+
+
B.5.3. Management / valorisation of public patrimony
+
+
Part 1: UML use case diagram
+
+
+
+
+
+
+
+
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.
+
+
+
Pre-condition
+
Building data is available
+
+
+
Flow of Events – Basic Path
+
+
+
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.
+
+
+
Data source: <Name> [repeat per data source]
+
+
+
Description
+
INSPIRE themes BU, PF, SO, CP, AD
+
+
+
Geographic scope
+
Everywhere in Europe
+
+
+
+
+
+
+
B.6. Census
+
+
B.6.1. European Census
+
+
Part 1: UML use case diagram
+
+
+
+
+
+
+
+
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 code list 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 _
+
+
+
+
+
+
+
+
+
Use Case Description
+
+
+
+
+
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).
+
+
+
Flow of Events – Basic Path
+
+
+
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.
+
+
+
Flow of Events – Alternative Paths
+
+
+
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.
+
+
+
+
Data source: <Name> [repeat per data source]
+
+
+
Description
+
INSPIRE themes SU, BU
+
+
+
Geographic scope
+
Everywhere in Europe
+
+
+
+
+
+
B.6.2. Census Units
+
+
Part 1: UML use case diagram
+
+
+
+
+
+
+
+
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.
+
+
+
+
+
+
+
+
+
Use Case Description
+
+
+
+
+
Name
+
Urban units
+
+
+
Priority
+
high
+
+
+
Description
+
The purpose is to define continuous urban areas, according to United Nations recommendations.
+
+
+
Pre-condition
+
+
+
+
Flow of Events – Basic Path
+
+
+
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
+
+
+
Data source: <Name> [repeat per data source]
+
+
+
Description
+
INSPIRE themes BU, US, TN, ..
+
+
+
Geographic scope
+
Everywhere in Europe
+
+
+
+
+
+
+
+
+
+
Annex C: Code list values
+
+
+
C.1. (normative)
+
+
INSPIRE Application Schema 'BuildingsBase'
+
+
+
+
+
+
+
+
Code List
+
+
+
+
+
BuildingNatureValue
+
+
+
ConditionOfConstructionValue
+
+
+
CurrentUseValue
+
+
+
ElevationReferenceValue
+
+
+
HeightStatusValue
+
+
+
HorizontalGeometryReferenceValue
+
+
+
+
+
BuildingNatureValue
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
Building nature value
+
+
+
Definition:
+
Values indicating the nature of a building.
+
+
+
Description:
+
NOTE 1 : This code list does not aim to be exhaustive as the attribute buildingNature addresses only noticeable buildings.
+NOTE 2: The values included in this code list address mainly (but not only) two international use cases: air flights where buildings may be obstacles and marine navigation where buildings may be landmarks.
+NOTE 3: This code list should only be applied for buildings, even if it may be applicable to other constructions (for example, not all dams are buildings).
The allowed values for this code list comprise the values specified in the INSPIRE Registry and additional values at any level defined by data providers.
+
+
+
+
+
+
+
+
ConditionOfConstructionValue
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
Condition of construction value
+
+
+
Definition:
+
Values indicating the condition of a construction.
The allowed values for this code list comprise only the values specified in the INSPIRE Registry.
+
+
+
+
+
+
+
+
CurrentUseValue
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
Current use value
+
+
+
Definition:
+
List of possible values indicating the current use.
+
+
+
Description:
+
SOURCE: This code list is partly based on and adapted from the Eurostat classification of types of constructions (for the classification of residential buildings).
+NOTE the values of this code list apply to buildings or building components where building components may be a building part (in core profiles) or a building unit (in extended profiles)
The allowed values for this code list comprise the values specified in the INSPIRE Registry and narrower values defined by data providers.
+
+
+
+
+
+
+
+
ElevationReferenceValue
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
Elevation reference value
+
+
+
Definition:
+
List of possible elements considered to capture a vertical geometry.
+
+
+
Description:
+
NOTE The values of this code list are used to describe the reference of elevation both where elevation has been captured as attribute or as Z coordinate.
List of values for the reference of official area, as defined in the CLGE measurement code for the floor area of buildings. SOURCE: http://www.eureal.eu/
The table below includes recommended values that may be used by data providers. Before creating new terms, please check if one of them can be used.
+
+
+
+
+
+
+
+
+
constructedArea
+
+
+
+
+
+
+
+
+
Name:
+
constructed area
+
+
+
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.
+
+
+
+
+
+
+
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.
+
+
+
+
+
+
+
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."
+
+
+
+
+
+
+
internalPrimaryArea
+
+
+
+
+
+
+
+
+
Name:
+
internal primary area
+
+
+
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…"
+
+
+
+
+
+
+
internalOtherArea
+
+
+
+
+
+
+
+
+
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, …)."
+
+
+
+
+
+
+
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 principal use of the building.
+
+
+
Description:
+
"Internal residual area includes in particular underground storage and archive rooms, cellars, parking garage, balconies, upper floor terraces, loggias."
+
+
+
+
+
+
+
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."
+
+
+
+
+
+
+
+
CurrencyValue
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
CurrencyValue
+
+
+
Definition:
+
Code list for possible values of attribute currency
+
+
+
Description:
+
NOTE 1: include currencies from all European countries, including that are not Member States of European Union.
+SOURCE: values are extracted from ISO 4217 standard.
+NOTE 2: this code list may be of interest not only for INSPIRE but also for other European applications and regulations ; so, in future, this code list might/should be managed outside INSPIRE.
The table below includes recommended values that may be used by data providers. Before creating new terms, please check if one of them can be used.
+
+
+
+
+
+
+
+
+
ALL
+
+
+
+
+
+
+
+
+
Name:
+
ALL
+
+
+
Definition:
+
Lek (in Albania)
+
+
+
+
+
+
+
BAM
+
+
+
+
+
+
+
+
+
Name:
+
BAM
+
+
+
Definition:
+
Convertible Mark (in Bosnia & Herzegovina)
+
+
+
+
+
+
+
BGN
+
+
+
+
+
+
+
+
+
Name:
+
BGN
+
+
+
Definition:
+
Bulgarian Lev (in Bulgaria)
+
+
+
+
+
+
+
BYR
+
+
+
+
+
+
+
+
+
Name:
+
BYR
+
+
+
Definition:
+
Belarussian Ruble (in Belarus)
+
+
+
+
+
+
+
CHE
+
+
+
+
+
+
+
+
+
Name:
+
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."
+
+
+
+
+
+
+
CHF
+
+
+
+
+
+
+
+
+
Name:
+
CHF
+
+
+
Definition:
+
Swiss Franc (in Switzerland and Liechtenstein)
+
+
+
+
+
+
+
CZK
+
+
+
+
+
+
+
+
+
Name:
+
CZK
+
+
+
Definition:
+
Czech Koruna (in Czech Republic)
+
+
+
+
+
+
+
DKK
+
+
+
+
+
+
+
+
+
Name:
+
DKK
+
+
+
Definition:
+
Danish Krone (in Denmark)
+
+
+
+
+
+
+
EUR
+
+
+
+
+
+
+
+
+
Name:
+
EUR
+
+
+
Definition:
+
euro
+
+
+
+
+
+
+
GBP
+
+
+
+
+
+
+
+
+
Name:
+
GBP
+
+
+
Definition:
+
Pound Sterling (in United Kingdom)
+
+
+
+
+
+
+
HRK
+
+
+
+
+
+
+
+
+
Name:
+
HRK
+
+
+
Definition:
+
Croatian Kuna (in Croatia)
+
+
+
+
+
+
+
HUF
+
+
+
+
+
+
+
+
+
Name:
+
HUF
+
+
+
Definition:
+
Forint (in Hungary)
+
+
+
+
+
+
+
ISK
+
+
+
+
+
+
+
+
+
Name:
+
ISK
+
+
+
Definition:
+
Iceland Krona (in Iceland)
+
+
+
+
+
+
+
LTL
+
+
+
+
+
+
+
+
+
Name:
+
LTL
+
+
+
Definition:
+
Lithuanian Litas (in Lithuania)
+
+
+
+
+
+
+
LVL
+
+
+
+
+
+
+
+
+
Name:
+
LVL
+
+
+
Definition:
+
Latvian Lats (in Latvia)
+
+
+
+
+
+
+
MDL
+
+
+
+
+
+
+
+
+
Name:
+
MDL
+
+
+
Definition:
+
Moldovan Leu (in Republic of Moldavia)
+
+
+
+
+
+
+
MKD
+
+
+
+
+
+
+
+
+
Name:
+
MKD
+
+
+
Definition:
+
Denar (in the former yugoslav republic of Macedonia)
+
+
+
+
+
+
+
NOK
+
+
+
+
+
+
+
+
+
Name:
+
NOK
+
+
+
Definition:
+
Norwegian Krone (in Norway)
+
+
+
+
+
+
+
PLN
+
+
+
+
+
+
+
+
+
Name:
+
PLN
+
+
+
Definition:
+
Zloty (in Poland)
+
+
+
+
+
+
+
RON
+
+
+
+
+
+
+
+
+
Name:
+
RON
+
+
+
Definition:
+
Leu (in Romania)
+
+
+
+
+
+
+
RSD
+
+
+
+
+
+
+
+
+
Name:
+
RSD
+
+
+
Definition:
+
Serbian Dinar (in Serbia)
+
+
+
+
+
+
+
RUB
+
+
+
+
+
+
+
+
+
Name:
+
RUB
+
+
+
Definition:
+
Russian Ruble (in Russian federation)
+
+
+
+
+
+
+
SEK
+
+
+
+
+
+
+
+
+
Name:
+
SEK
+
+
+
Definition:
+
Swedish Krona (in Sweden)
+
+
+
+
+
+
+
TRY
+
+
+
+
+
+
+
+
+
Name:
+
TRY
+
+
+
Definition:
+
Turkish Lira (in Turkey)
+
+
+
+
+
+
+
UAH
+
+
+
+
+
+
+
+
+
Name:
+
UAH
+
+
+
Definition:
+
Hryvnia (in Ukraine)
+
+
+
+
+
+
+
+
EnergyPerformanceValue
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
EnergyPerformanceValue
+
+
+
Definition:
+
Code list for possible values of energy performance of a building or building part or building unit.
The table below includes recommended values that may be used by data providers. Before creating new terms, please check if one of them can be used.
+
+
+
+
+
+
+
+
+
centralHeating
+
+
+
+
+
+
+
+
+
Name:
+
central heating
+
+
+
Definition:
+
Central heating system performed at building or at building unit level.
+
+
+
+
+
+
+
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.
+
+
+
+
+
+
+
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.
+
+
+
+
+
+
+
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.
+
+
+
+
+
+
+
portableGasHeating
+
+
+
+
+
+
+
+
+
Name:
+
portable gas heating
+
+
+
Definition:
+
Heating is performed by a portable device using liquefied petroleum gas.
+
+
+
+
+
+
+
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.
+
+
+
+
+
+
+
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."
+
+
+
+
+
+
+
+
InstallationNatureValue
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
InstallationNatureValue
+
+
+
Definition:
+
Code list giving the possible values of an installation nature.
The table below includes recommended values that may be used by data providers. Before creating new terms, please check if one of them can be used.
+
+
+
+
+
+
+
+
+
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 external air conditioning units located outside the building shall be considered as Installation.
+
+
+
+
+
+
+
airDuct
+
+
+
+
+
+
+
+
+
Name:
+
air duct
+
+
+
Definition:
+
Ducts for incoming (fresh) and outgoing (stale) air.
+
+
+
+
+
+
+
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
+
+
+
+
+
+
+
arcade
+
+
+
+
+
+
+
+
+
Name:
+
arcade
+
+
+
Definition:
+
An arcade is a covered passage, usually with shops on one or both sides.
+
+
+
+
+
+
+
balcony
+
+
+
+
+
+
+
+
+
Name:
+
balcony
+
+
+
Definition:
+
A balcony is a upper accessible platform within a storey, not fully enclosed by wall(s).
+
+
+
+
+
+
+
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.
+
+
+
+
+
+
+
cradle
+
+
+
+
+
+
+
+
+
Name:
+
cradle
+
+
+
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.
+
+
+
+
+
+
+
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.
+
+
+
+
+
+
+
externalLift
+
+
+
+
+
+
+
+
+
Name:
+
external lift
+
+
+
Definition:
+
Lift moving along the outside of a building.
+
+
+
+
+
+
+
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.
+
+
+
+
+
+
+
ramp
+
+
+
+
+
+
+
+
+
Name:
+
ramp
+
+
+
Definition:
+
A ramp is an inclined plane installed in addition to or instead of stairs. A ramp may generally be used by wheelchairs.
+
+
+
+
+
+
+
solarPanel
+
+
+
+
+
+
+
+
+
Name:
+
solar panel
+
+
+
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.
+
+
+
+
+
+
+
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.
+
+
+
+
+
+
+
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."
+
+
+
+
+
+
+
windTurbine
+
+
+
+
+
+
+
+
+
Name:
+
wind turbine
+
+
+
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.
+
+
+
+
+
+
+
+
MaterialOfFacadeValue
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
MaterialOfFacadeValue
+
+
+
Definition:
+
Code list for the possible values of MaterialOfFacade
The table below includes recommended values that may be used by data providers. Before creating new terms, please check if one of them can be used.
+
+
+
+
+
+
+
+
+
adobe
+
+
+
+
+
+
+
+
+
Name:
+
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.
+
+
+
+
+
+
+
asbestos
+
+
+
+
+
+
+
+
+
Name:
+
asbestos
+
+
+
Definition:
+
Fa?ade constructed out of asbestos.
+
+
+
+
+
+
+
ceramicTiles
+
+
+
+
+
+
+
+
+
Name:
+
ceramic tiles
+
+
+
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.
+
+
+
+
+
+
+
composite
+
+
+
+
+
+
+
+
+
Name:
+
composite
+
+
+
Definition:
+
Composite material, such as plastics, PVC and fibreglass are used to cover the fa?ade of the building.
+
+
+
+
+
+
+
concrete
+
+
+
+
+
+
+
+
+
Name:
+
concrete
+
+
+
Definition:
+
The surface of the fa?ade is constructed out of (reinforced, with bars or fibres-other than asbestos) concrete.
+
+
+
+
+
+
+
glass
+
+
+
+
+
+
+
+
+
Name:
+
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.
+
+
+
+
+
+
+
limestone
+
+
+
+
+
+
+
+
+
Name:
+
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."
+
+
+
+
+
+
+
masonry
+
+
+
+
+
+
+
+
+
Name:
+
masonry
+
+
+
Definition:
+
The fa?ade consists of individual units made of fired clay brick or concrete block laid in and bound together by mortar.
+
+
+
+
+
+
+
metal
+
+
+
+
+
+
+
+
+
Name:
+
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.
+
+
+
+
+
+
+
naturalStone
+
+
+
+
+
+
+
+
+
Name:
+
natural stone
+
+
+
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."
+
+
+
+
+
+
+
vegetated
+
+
+
+
+
+
+
+
+
Name:
+
vegetated
+
+
+
Definition:
+
The fa?ade is covered with vegetation and a growing medium, planted over a waterproofing membrane
+
+
+
+
+
+
+
wood
+
+
+
+
+
+
+
+
+
Name:
+
wood
+
+
+
Definition:
+
The fa?ade of the building is covered with wood, timber or lumber.
+
+
+
+
+
+
+
+
MaterialOfRoofValue
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
MaterialOfRoofValue
+
+
+
Definition:
+
Code list for possible values of attribute MaterialOfRoof
The table below includes recommended values that may be used by data providers. Before creating new terms, please check if one of them can be used.
+
+
+
+
+
+
+
+
+
asbestos
+
+
+
+
+
+
+
+
+
Name:
+
asbestos
+
+
+
Definition:
+
Fibre reinforced concrete that includes asbestos fibres.
+
+
+
Description:
+
"NOTE It is commonly used for the agricultural sector, particularly in livestock buildings."
+
+
+
+
+
+
+
ceramicTile
+
+
+
+
+
+
+
+
+
Name:
+
ceramic tile
+
+
+
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.
+
+
+
+
+
+
+
clayTile
+
+
+
+
+
+
+
+
+
Name:
+
clay tile
+
+
+
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.
+
+
+
+
+
+
+
composition
+
+
+
+
+
+
+
+
+
Name:
+
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.
+
+
+
+
+
+
+
concreteTile
+
+
+
+
+
+
+
+
+
Name:
+
concrete tile
+
+
+
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."
+
+
+
+
+
+
+
corrugatedSheet
+
+
+
+
+
+
+
+
+
Name:
+
corrugated sheet
+
+
+
Definition:
+
Roofs of corrugated sheet may be of fibreglass, PVC or metal; less frequent is the use of galvanized iron sheet.
+
+
+
+
+
+
+
glass
+
+
+
+
+
+
+
+
+
Name:
+
glass
+
+
+
Definition:
+
The surface of the roof is constructed out of glass, typically used in roofs covering internal atriums or in greenhouses.
+
+
+
+
+
+
+
hotMoppedAsphalt
+
+
+
+
+
+
+
+
+
Name:
+
hot mopped asphalt
+
+
+
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.
+
+
+
+
+
+
+
metal
+
+
+
+
+
+
+
+
+
Name:
+
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."
+
+
+
+
+
+
+
reinforcedConcrete
+
+
+
+
+
+
+
+
+
Name:
+
reinforced concrete
+
+
+
Definition:
+
Roofs constructed out of reinforced concrete, normally along flat or semi-flat surfaces used in terraces or inclined roofs.
+
+
+
+
+
+
+
slate
+
+
+
+
+
+
+
+
+
Name:
+
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."
+
+
+
+
+
+
+
thatch
+
+
+
+
+
+
+
+
+
Name:
+
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.
+
+
+
+
+
+
+
vegetatedGreenRoof
+
+
+
+
+
+
+
+
+
Name:
+
vegetated green roof
+
+
+
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.
+
+
+
+
+
+
+
woodShinglesOrShakes
+
+
+
+
+
+
+
+
+
Name:
+
wood shingles or shakes
+
+
+
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.
+
+
+
+
+
+
+
+
MaterialOfStructureValue
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
MaterialOfStructureValue
+
+
+
Definition:
+
Code list for possible values of attribute MaterialOfStructure.
The table below includes recommended values that may be used by data providers. Before creating new terms, please check if one of them can be used.
+
+
+
+
+
+
+
+
+
reinforcedConcrete
+
+
+
+
+
+
+
+
+
Name:
+
reinforced concrete
+
+
+
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.
+
+
+
+
+
+
+
reinforcedMasonry
+
+
+
+
+
+
+
+
+
Name:
+
reinforced masonry
+
+
+
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.
+
+
+
+
+
+
+
rubleStoneMasonry
+
+
+
+
+
+
+
+
+
Name:
+
ruble stone masonry
+
+
+
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."
+
+
+
+
+
+
+
steel
+
+
+
+
+
+
+
+
+
Name:
+
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.
+
+
+
+
+
+
+
stoneMasonryBlock
+
+
+
+
+
+
+
+
+
Name:
+
stone masonry block
+
+
+
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.
+
+
+
+
+
+
+
wood
+
+
+
+
+
+
+
+
+
Name:
+
wood
+
+
+
Definition:
+
The load resisting system of the building is made of wood, timber or lumber.
+
+
+
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. This category is also known as timber framing or half-timbered."
+
+
+
+
+
+
+
adobeBlockWalls
+
+
+
+
+
+
+
+
+
Name:
+
adobe Block Walls
+
+
+
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."
+
+
+
+
+
+
+
concreteBlockMasonry
+
+
+
+
+
+
+
+
+
Name:
+
concrete block masonry
+
+
+
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."
+
+
+
+
+
+
+
earth
+
+
+
+
+
+
+
+
+
Name:
+
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."
+
+
+
+
+
+
+
firedBrickMasonry
+
+
+
+
+
+
+
+
+
Name:
+
fired brick masonry
+
+
+
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.
+
+
+
+
+
+
+
informalConstructions
+
+
+
+
+
+
+
+
+
Name:
+
informal constructions
+
+
+
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."
+
+
+
+
+
+
+
massiveStoneMasonry
+
+
+
+
+
+
+
+
+
Name:
+
massive stone masonry
+
+
+
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.
+
+
+
+
+
+
+
mobileHomes
+
+
+
+
+
+
+
+
+
Name:
+
mobile homes
+
+
+
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."
+
+
+
+
+
+
+
mudWalls
+
+
+
+
+
+
+
+
+
Name:
+
mud walls
+
+
+
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."
+
+
+
+
+
+
+
precastConcrete
+
+
+
+
+
+
+
+
+
Name:
+
precast concrete
+
+
+
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.
+
+
+
+
+
+
+
+
OfficialValueReferenceValue
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
OfficialValueReferenceValue
+
+
+
Definition:
+
The list of possible values for referencing the official value of a building, building part or building unit.
The table below includes recommended values that may be used by data providers. Before creating new terms, please check if one of them can be used.
+
+
+
+
+
+
+
+
+
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.
+
+
+
+
+
+
+
transactionPriceMedium
+
+
+
+
+
+
+
+
+
Name:
+
transaction price medium
+
+
+
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.
+
+
+
+
+
+
+
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.
+
+
+
+
+
+
+
rentalIncome
+
+
+
+
+
+
+
+
+
Name:
+
rental income
+
+
+
Definition:
+
The reference for official value is the rental income for the building or building unit, according to market prices.
+
+
+
+
+
+
+
+
OtherConstructionNatureValue
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
OtherConstructionNatureValue
+
+
+
Definition:
+
Code list for the attribute other construction nature.
The table below includes recommended values that may be used by data providers. Before creating new terms, please check if one of them can be used.
+
+
+
+
+
+
+
+
+
cityWall
+
+
+
+
+
+
+
+
+
Name:
+
city wall
+
+
+
Definition:
+
A fortification (usually historic) used to defend a city or settlement or used to enclose settlements.
+
+
+
+
+
+
+
crane
+
+
+
+
+
+
+
+
+
Name:
+
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.
+
+
+
+
+
+
+
monument
+
+
+
+
+
+
+
+
+
Name:
+
monument
+
+
+
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) or by their fame are especially expected by INSPIRE."
+
+
+
+
+
+
+
openAirPool
+
+
+
+
+
+
+
+
+
Name:
+
open air pool
+
+
+
Definition:
+
A swimming-pool that is not covered.
+
+
+
Description:
+
Open-air pools are of interest for fire risk.
+
+
+
+
+
+
+
protectiveStructure
+
+
+
+
+
+
+
+
+
Name:
+
protective structure
+
+
+
Definition:
+
A construction providing protection against environmental hazrds, such as avalanches, mudslides, rock falls and landslides etc.
+
+
+
+
+
+
+
pylon
+
+
+
+
+
+
+
+
+
Name:
+
pylon
+
+
+
Definition:
+
Any elongated tall support structure used to support an overhead power line.
+
+
+
+
+
+
+
retainingWall
+
+
+
+
+
+
+
+
+
Name:
+
retaining wall
+
+
+
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.
+
+
+
+
+
+
+
solarPanel
+
+
+
+
+
+
+
+
+
Name:
+
solar panel
+
+
+
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."
+
+
+
+
+
+
+
substation
+
+
+
+
+
+
+
+
+
Name:
+
substation
+
+
+
Definition:
+
Part of an electrical generation, transmission and distribution system where voltage is transformed from high to low, or the reverse.
+
+
+
+
+
+
+
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).
+
+
+
+
+
+
+
acousticFence
+
+
+
+
+
+
+
+
+
Name:
+
acoustic fence
+
+
+
Definition:
+
Environmental noise barrier system.
+
+
+
+
+
+
+
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.
+
+
+
+
+
+
+
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.
+
+
+
+
+
+
+
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.
+
+
+
+
+
+
+
+
RoofTypeValue
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
RoofTypeValue
+
+
+
Definition:
+
Code list for the possible values of attribute roofType.
The table below includes recommended values that may be used by data providers. Before creating new terms, please check if one of them can be used.
+
+
+
+
+
+
+
+
+
archRoof
+
+
+
+
+
+
+
+
+
Name:
+
arch roof
+
+
+
Definition:
+
A roof taking the form of a semicircular span connected.
+
+
+
+
+
+
+
conicalRoof
+
+
+
+
+
+
+
+
+
Name:
+
conical roof
+
+
+
Definition:
+
An inverted cone roof construction usually atop of a cylindrical tower.
+
+
+
+
+
+
+
domedRoof
+
+
+
+
+
+
+
+
+
Name:
+
domed roof
+
+
+
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."
+
+
+
+
+
+
+
dualPentRoof
+
+
+
+
+
+
+
+
+
Name:
+
dual Pent roof
+
+
+
Definition:
+
A roof that has two or more single plane roofs, usually separated or connected by vertical walls.
+
+
+
+
+
+
+
flatRoof
+
+
+
+
+
+
+
+
+
Name:
+
flat roof
+
+
+
Definition:
+
Roof either horizontal or with a slope of 10? or less.
+
+
+
+
+
+
+
gabledRoof
+
+
+
+
+
+
+
+
+
Name:
+
gabled roof
+
+
+
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
+
+
+
+
+
+
+
halfHippedRoof
+
+
+
+
+
+
+
+
+
Name:
+
half Hipped roof
+
+
+
Definition:
+
A roof where all planes slope down to the supporting walls but with the upper point of the gable squared off.
+
+
+
+
+
+
+
hippedRoof
+
+
+
+
+
+
+
+
+
Name:
+
hipped roof
+
+
+
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
+
+
+
+
+
+
+
hyperbolicParabaloidalRoof
+
+
+
+
+
+
+
+
+
Name:
+
hyperbolic parabaloidal roof
+
+
+
Definition:
+
A roof constructed with two axes with one plane following a convex curve and another a concave curve.
+
+
+
+
+
+
+
mansardRoof
+
+
+
+
+
+
+
+
+
Name:
+
mansard roof
+
+
+
Definition:
+
Pitched roof with two inclined planes on each side of the ridge , the steeper of the two starting at the eaves
+
+
+
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.
+
+
+
+
+
+
+
monopitchRoof
+
+
+
+
+
+
+
+
+
Name:
+
monopitch roof
+
+
+
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 %).
+
+
+
+
+
+
+
pavilionRoof
+
+
+
+
+
+
+
+
+
Name:
+
pavilion roof
+
+
+
Definition:
+
A roof construction with equal hips on all planes, usually taking the form of a pyramidal shape.
+
+
+
+
+
+
+
pyramidalBroachRoof
+
+
+
+
+
+
+
+
+
Name:
+
pyramidal broach roof
+
+
+
Definition:
+
A suspended roof construction with all four planes meeting at a central point.
+
+
+
+
+
+
+
sawToothRoof
+
+
+
+
+
+
+
+
+
Name:
+
saw tooth roof
+
+
+
Definition:
+
Series of pitched roofs , each with one inclined plane steeper than the other and fully or partially glazed
+
+
+
+
+
+
+
+
SourceStatusValue
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
SourceStatusValue
+
+
+
Definition:
+
Code list for possible values of attribute sourceStatus (of Document).
The table below includes recommended values that may be used by data providers. Before creating new terms, please check if one of them can be used.
+
+
+
+
+
+
+
+
+
NotOfficial
+
+
+
+
+
+
+
+
+
Name:
+
not official
+
+
+
Definition:
+
The document initially comes from a non-official source, without validation by a public body.
+
+
+
Description:
+
"EXAMPLE: The document may provide from the voluntary contribution of citizens (Volonteer Geographic Information) that has been integrated in the data of a public body, without any control process."
+
+
+
+
+
+
+
Official
+
+
+
+
+
+
+
+
+
Name:
+
official
+
+
+
Definition:
+
The document is provided from an official source.
+
+
+
+
+
+
+
+
INSPIRE Application Schema 'BuildingsExtended3D'
+
+
+
+
+
+
+
+
Code List
+
+
+
+
+
InternalInstallationNatureValue
+
+
+
MimeTypeValue
+
+
+
RoomNatureValue
+
+
+
TextureTypeValue
+
+
+
+
+
InternalInstallationNatureValue
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Name:
+
InternalInstallationNatureValue
+
+
+
Definition:
+
Code list for the possible values of the nature of an internal installation.
The table below includes recommended values that may be used by data providers. Before creating new terms, please check if one of them can be used.
+
+
+
+
+
+
+
+
+
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.
+
+
+
+
+
+
+
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.
+
+
+
+
+
+
+
elevator
+
+
+
+
+
+
+
+
+
Name:
+
elevator
+
+
+
Definition:
+
An elevator is a type of vertical transport equipment that efficiently moves people or goods between floors of a building.
+
+
+
+
+
+
+
escalator
+
+
+
+
+
+
+
+
+
Name:
+
escalator
+
+
+
Definition:
+
Moving stairs that carry people between different floors of a large building.
+
+
+
+
+
+
+
fireside
+
+
+
+
+
+
+
+
+
Name:
+
fireside
+
+
+
Definition:
+
A fireside or fireplace is an architectural structure designed to contain a fire for heating, as well as for cooking.
+
+
+
+
+
+
+
oven
+
+
+
+
+
+
+
+
+
Name:
+
oven
+
+
+
Definition:
+
An oven is a thermally insulated chamber used for the heating, baking or drying of a substance.
+
+
+
+
+
+
+
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.
+
+
+
+
+
+
+
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.
+
+
+
+
+
+
+
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.
+
+
+
+
+
+
+
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.
+
+
+
+
+
+
+
stairs
+
+
+
+
+
+
+
+
+
Name:
+
stairs
+
+
+
Definition:
+
Stairs are 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.
+
+
+
+
+
+
+
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."
The table below includes recommended values that may be used by data providers. Before creating new terms, please check if one of them can be used.
+
+
+
+
+
+
+
+
+
agriculture
+
+
+
+
+
+
+
+
+
Name:
+
agriculture
+
+
+
Definition:
+
A room related to the cultivation of animals, plants, fungi and other life forms for food, fiber, wood wood and other products used to sustain life.
+
+
+
+
+
+
+
buildingEquipment
+
+
+
+
+
+
+
+
+
Name:
+
building equipment
+
+
+
Definition:
+
A room used to operate technical equipment.
+
+
+
Description:
+
EXAMPLE: an electrical room
+
+
+
+
+
+
+
catering
+
+
+
+
+
+
+
+
+
Name:
+
catering
+
+
+
Definition:
+
A room used for catering purposes, i.e. to prepare or to serve meals outside the home. This includes restaurants, school and hospital cafeterias and catering operations.
+
+
+
+
+
+
+
clerical
+
+
+
+
+
+
+
+
+
Name:
+
clerical
+
+
+
Definition:
+
A room dedicated to clerical purposes.
+
+
+
+
+
+
+
communication
+
+
+
+
+
+
+
+
+
Name:
+
communication
+
+
+
Definition:
+
A room related to the transmission of information over significant distances to communicate.
+
+
+
+
+
+
+
educationOrResearch
+
+
+
+
+
+
+
+
+
Name:
+
education or research
+
+
+
Definition:
+
A room used to teach or educate people or related to research.
+
+
+
Description:
+
EXAMPLES: a classroom or a lecture hall
+
+
+
+
+
+
+
habitation
+
+
+
+
+
+
+
+
+
Name:
+
habitation
+
+
+
Definition:
+
A room used for dwelling purposes.
+
+
+
Description:
+
EXAMPLES: a living room or a bedroom.
+
+
+
+
+
+
+
healthCare
+
+
+
+
+
+
+
+
+
Name:
+
health care
+
+
+
Definition:
+
A room used for the purpose of the prevention, treatment and management of illness.
+
+
+
+
+
+
+
industry
+
+
+
+
+
+
+
+
+
Name:
+
industry
+
+
+
Definition:
+
A room related to the production of an economic good or service within an economy.
+
+
+
+
+
+
+
office
+
+
+
+
+
+
+
+
+
Name:
+
office
+
+
+
Definition:
+
A room dedicated to (public or private) administrative purposes.
+
+
+
+
+
+
+
publicTechnicalInfrastructure
+
+
+
+
+
+
+
+
+
Name:
+
public technical infrastructure
+
+
+
Definition:
+
A room dedicated to proposes of hard infrastructure (energy, water management, solid waste), for benefit of public, excluding communication and transportation.
+
+
+
+
+
+
+
recreation
+
+
+
+
+
+
+
+
+
Name:
+
recreation
+
+
+
Definition:
+
A room which is used for leisure, leisure being discretionary time.
+
+
+
+
+
+
+
store
+
+
+
+
+
+
+
+
+
Name:
+
store
+
+
+
Definition:
+
A room where goods are stored.
+
+
+
+
+
+
+
trade
+
+
+
+
+
+
+
+
+
Name:
+
trade
+
+
+
Definition:
+
A room related to the trade of goods or services.
+
+
+
Description:
+
EXAMPLE: a shop
+
+
+
+
+
+
+
transportation
+
+
+
+
+
+
+
+
+
Name:
+
transportation
+
+
+
Definition:
+
A room used for transportation purposes. Transportation is the movement of people, animals and goods from one location to another.
The table below includes recommended values that may be used by data providers. Before creating new terms, please check if one of them can be used.
+
+
+
+
+
+
+
+
+
specific
+
+
+
+
+
+
+
+
+
Name:
+
specific
+
+
+
Definition:
+
Specific means that the texture has been captured individually for that particular building.
+
+
+
+
+
+
+
typical
+
+
+
+
+
+
+
+
+
Name:
+
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).
+
+
+
+
+
+
+
+
+
+
+
+
Annex D: CityGML and its role in INSPIRE Buildings data specification - (informative)
+
+
+
D.1. Introduction
+
+
D.1.1. Objectives and principles
+
+
CityGML is a common model for the representation and the exchange of 3D city models.
+
+
+
There are three main design goals of CityGML:
+
+
+
+
+
The representation of semantics and relations between objects. In contrast to 3D city models provided in graphical or geometrical formats such as 3D Studio MAX/3ds Max, KML, X3D or OpenStreetMap-3D, the focus of CityGML is on the semantics of objects and its structures (aggregations, relations). Features like buildings and its components on different levels (building parts, rooms, wall or roof surfaces, doors, windows, balconies, dormers) are classified semantically and further described by attributes (function, year of construction, …). Furthermore, the relations between those features are explicitly represented, e.g. a relation of a door to the wall surface it contains. The representation of semantics is inevitable for many relevant applications of 3D city models like non-photorealistic rendering according to attribute values (e.g., to building function), spatial analyses like computing the visibility of a location from windows, balconies of flat roofs, or computing the flood level when a door or a window is affected by water. Other applications that require semantics are disaster management, homeland security, real estate management, vehicle and pedestrian navigation and training simulators.
+
+
+
Interoperability. The lossless and smooth exchange of 3D city models between different systems, formats and organizations is facilitated by defining a common semantical model and common levels of detail, as well as by the use of standards like GML, which are based on ISO standard like ISO 19107 (Herring, 2001) and ISO 19109 (International Organization for Standardization, ISO TC 211, 2005).
+
+
+
Base model. CityGML defines the semantical objects, attributes and relations which are required by most applications. It is a base model in the tradition of European topographic or cadastral models, which can be used by multi-functionally by many applications. It is not designed as a model for specific applications. For such specific applications like indoor navigation, energy assessment or noise simulation and mapping, CityGML can be extended by adding feature types or by adding properties to existing feature types. For such extensions, CityGML provides an uniform mechanism called ADE (Application Domain Extension).
+
+
+
+
+
Fig. 1 and Fig. 2 depict two examples for 3D city models in different levels of detail that are represented in CityGML.
+
+
+
+
+
+
+
+
Fig. 1: Very detailed 3D city model (Level-of-Detail 3) in CityGML (image: www.de.maila-push.com)
+
+
+
+
+
+
+
+
Fig. 2: Low detailed CityGML 3D city model (Level-of-Detail 1) applied for noise emission simulation (Czerwinski et al., 2007)
+
+
+
CityGML defines the geometry, semantics and appearance of topographic objects in urban or rural regions. These objects are divided into thematic modules: the building module, the vegetation module, the transportation module, the water body module, the city furniture module and the digital terrain model module. Fig. 3 gives an overview of the thematic modules of CityGML. However, the focus of that chapter is on the building model, which is most relevant for the scope of TWG BU.
+
+
+
+
+
+
+
+
Fig. 3: UML package diagram illustrating the separate modules of CityGML and their schema dependencies (Gröger et al. 2012).
+
+
+
+
D.1.2. Context
+
+
Development of City GML
+
+
+
City GML is an international standard of the Open Geospatial Consortium (OGC, see www.opengeospatial.org) since 2008, based on the Geographic Markup Language GML 3.1.1. (Cox et al., 2003). Version 2.0 of CityGML has been published in 2012.
+
+
+
CityGML has been developed since 2003 (and is developed further) by the Special Interest Group 3D (SIG 3D) of the initiative Spatial Data Infrastructure Germany (GDI-DE), see www.sig3d.org. Until 2010, the SID 3D was affiliated to the more local GDI.NRW of North Rhine Westphalia.The development of CityGML was motivated by the observations that most existing 3D city models were represented purely geometrically or graphically, and that no standard for semantical 3D city models was available. Since 2008, CityGML is an OGC standard.
+
+
+
+
+
D.2. Evolutions of CityGML
+
+
Currently, version 1.0 of CityGML is widely in use (see Gröger et al, 2008). Version 2.0 (see Gröger et al, 2012) was adopted as OGC standard in March 2012. In this version, semantical models for bridges and tunnels have been added and the building model has been enriched, e.g. by adding a 2.5D representation.
+
+
+
Use of City GML
+
+
+
Many commercial tools support CityGML by providing export or import of CityGML data sets: Oracle Spatial 11g (3D data types and CityGML loader), Safe Software FME, Autodesk Land Explorer, Snowflake Go Publisher WFS, interactive instruments: XtraServer/WFS, Bitmanagement BS Contact Geo, GTA tridicon City Discoverer, Google Sketch up (GEORES), Bentley Map and MetGeoInfo CityGRID.
+
+
+
CityGML has been disseminated worldwide. Examples are the Bati3D project in France, 3D city models of Zürich, Geneva, Monaco and 13 cities in Denmark, 3D city models of Leeuwarden in The Netherlands, projects in Kuala Lumpur, Malaysia, in Istanbul, Turkey, in Wuhan, China and in Korea.
+
+
+
For more details on CityGML see Gröger et al. (2012), Gröger & Plümer (2012) or Kolbe et al. (2008). The next two sections focus on the two aspects which are most relevant for the TWG BU model: the building and the appearance model of CityGML.
+
+
+
+
D.3. Building Model
+
+
The building model is the most important component of CityGML. It enables the representation of buildings and its parts (buildings parts, walls, roofs, windows, doors, rooms, balconies, …) with regard to geometry as well as to semantics (feature types and properties). In this chapter, the Building model of City GML version 2.0 is introduced.
+
+
+
The geometry model that is employed to represent buildings (as well as to represent other features in CityGML) is based on the well-known Boundary Representation (BRep) (Mäntylä, 1988), which represents volume objects like buildings by three-dimensional solids. The extent of a solid is defined by its bounding surfaces, which delimit the solids without overlaps and without gaps (water tightness). In CityGML, all solids are bounded by planar polygons. Solids representing the geometries of a simple building with a gabled roof and a garage are depicted in Fig. 4. In CityGML, the geometry model (as well as the optional topology model) of GML 3.1, which is based on the standard ISO 19107 'Spatial Schema' (Herring, 2001), is used.
+
+
+
+
+
+
+
+
Fig. 4: Example of a Boundary Representation model consisting of two solids. The left solid is bounded by seven rectangles and the right one by six.
+
+
+
The restriction to planar surfaces is due to the restrictions of many tools or spatial data bases which can not deal with non-linear surfaces such as cylinder or spheric surfaces. In Fig. 5, a roof with a chimney and a dormer is depicted which is represented by a composite surface consisting of planar surfaces (total of 16 surfaces, 5 for the dormer and 5 for the chimney). In general, all shapes (including spherical or cylindes shapes) can be approximated by planar surfaces with an arbitrary small error. The smaller the error is, the smaller the surfaces are. Often triangulations are used for this purpose.
+
+
+
+
+
+
+
+
Fig. 5: Representation of a roof and its structures by planar surfaces.
+
+
+
Each feature that is defined in CityGML (buildings, building parts, rooms, wall surfaces, roof surfaces, doors, windows, etc.) has common attributes. These attributes are a creation and a destruction date as well as an external reference pointing to the identifier of the object in another information system, typically in the system the object initially was obtained from (e.g., in the German cadastre system ALKIS, in the German topographic information system ATKIS, or in the OS MasterMap®). This reference facilitates updates of CityGML features and supports the retrieval of additional information, e.g. of the owner of a building from a cadastral system. Furthermore, all CityObjects inherit a name, a description and metadata according to ISO 19115 (International Organization for Standardization, ISO TC 211, 2003) (lineage, accuracy, topological consistency, …) from corresponding GML classes. Fig. 5 shows the UML diagram of the core module which defines the class _CityObject.
+
+
+
+
+
+
+
+
Fig. 6: Properties of the base class _CityObject which are inherited by all features in CityGML (Gröger et al. 2012)
+
+
+
Buildings as well as all features in CityGML are represented in different levels of detail. Five consecutive Levels of Detail (LoD) are defined, where features become more detailed with increasing LoD regarding both their geometry and semantic differentiation. CityGML features as well as data sets can - but do not have to - contain multiple representations (and geometries) for each object in different LoD simultaneously. This enables the analysis and visualisation of the same object with regard to different degrees of resolution. LoDs are required to reflect independent data collection processes with differing application requirements. Furthermore, the classification into LoDs facilitates interoperability, since preferably features with the same LoD can be integrated. In the following, the LoDs of CityGML – LoD0 to LoD4 – are introduced. Fig. 6 provides examples for those LoDs.
+
+
+
In all LoDs, buildings are represented by the class Building, the attributes of which are inherited from the base class _AbstractBuilding. The attributes are a classification of the building (attribute class: public building, …), the function (dwelling, office building, …) and the usage in the case the actual usage differs from the intended function. The other attributes represent the year of construction/demolition, the roof type (given as an code list of the main types flat, monopitch, gabled, …), the actual measured height of the building and the numbers and actual heights of the stories above and below ground. The address of the building is given by the reference to an address object (using the OASIS standard for addresses).
+
+
+
A building can consist of building parts, The distinction into BuildingParts accommodates the fact that components of a building differ with regard to geometry (different heights, for example) or attributes (YearOfConstruction, RoofType, …). Buildings and BuildingParts potentially have the same spatial and non spatial properties, since both are sub classes of _AbstractBuilding. Both must be consistent: If parts are present, the building geometry is represented for the parts only. The attribute values of a part apply only to that part, whereas attribute values of a building refer to all parts. Fig. 7 shows an example for a building consisting of two parts.
+
+
+
+
+
+
+
+
Building model in LoD1 to LoD4. In LoD0 (not shown on the figure), only the topmost (or bottommost) rectangle of the LoD1 box is represented (image: KIT Karlsruhe)
+
+
+
+
+
+
+
+
Examples of a building that consists of two parts (left) and of a building that consists of one part (right)
+
+
+
D.3.1. Level of Detail 0 (LoD0)
+
+
In LOD0, a building is represended by horizontal 3D surfaces (2.5D). These surfaces are either at foot print level (relation lod0FootPrint) or at eaves height level (lod0RoofEgde). The UML diagram for LoD0 is given in Fig. 9.
+
+
+
+
+
+
+
+
Fig. 7: UML diagram of CityGML’s building model: LoD0[17]
+
+
+
+
D.3.2. Level of Detail 1 (LoD1)
+
+
The coarsest volumetric Level of Detail 1 represents buildings as blocks model, i.e. prismatic buildings with flat roofs (c.f. Fig. 6a). The UML diagram for this LoD is given in Fig. 10.
+
+
+
The geometry of LoD1 is represented by a solid (association lod1Solid), which is specified by the language GML as Boundary Representation (c.f. Fig. 4). The solid geometry covers the case where the geometry is completely bounded by surfaces. Alternatively, a MultiSurface geometry (association lod1MultiSurface) allows for building geometries that are not 'water tight', e.g. a geometry without ground surface. Such models occur frequently in practice and should not be excluded. The terrain intersection curve, which is available in each LoD, explicitly represents the line where the building touches the surface of the terrain. That concept facilitates the smooth integration of the building into the terrain.
+
+
+
+
+
+
+
+
Fig. 8: UML diagram of CityGML’s building model: LoD1
+
+
+
+
D.3.3. Level of Detail 2 (LoD2)
+
+
Geometrically, a building in LoD2 provides the prototypic, i.e. generalized, roof shape, optionally including roof overhangs. The walls are represented geometrically by vertical surfaces, as in Lod1. Semantically, a LoD2 building has thematically differentiated surfaces particularly for the roof and the walls. The UML diagram for this LoD is depicted in Fig. 11. The semantic aspects of the classes Building, BuildingPart and _AbstractBuilding are identical to LoD1. The geometry is represented again either as a Solid or as a MultiSurface, which both are more detailed. The Lod2 geometry is distinguished from the LoD1 geometry by using different association names (lod2Solid, lod2MultiSurface, lod2TerrainIntersection). Note that LoD1 and LoD2 (as well as LoD3 and 4) are not used in a mutually exclusive way: a single building can simultaneously be represented in more than one LoD. Such a multiple representation is enabled by providing distinct names for geometry associations for each LoD.
+
+
+
+
+
+
+
+
Fig. 9: UML diagram of CityGML’s building model: LoD2
+
+
+
In LoD2 boundary surfaces can be represented not only on a geometrical level (as part of a solid geometry), but on a semantical level as BoundarySurface_ features. Such a feature can be a RoofSurface, a WallSurface, a GroundSurface, a ClosureSurface, an OuterCeilingSurface and anOuterFloorSurface[18].__ In order to avoid duplicated, redundant geometries, the geometry of a thematic Boundary Surface must be shared with the corresponding solid geometry of the building. Fig. 12 illustrates this concept.
+
+
+
In LoD2 BuildingInstallations are added in addition, which represent small extensions like balconies, chimneys or outer stairs semantically.
+
+
+
+
+
+
+
+
Fig. 10: Sharing of geometries: The right surface of the building (depicted hatched) is part of a solid geometry as well as part of the WallSurface geometry
+
+
+
+
D.3.4. Level of Detail 3 (LoD3)
+
+
LoD3 is the most detailed level for the outermost shape of objects (see Fig. 1). This level denotes architectural models with detailed facade and roof structures such as balconies, bays, projections, dormers and chimneys. These objects are represented gemetrically as well as semantically. High-resolution textures can be mapped onto these structures. An example for a LoD3 building is given in Fig. 6c and the corresponding UML diagram in Fig. 13.
+
+
+
+
+
+
+
+
Fig. 11: UML diagram of CityGML’s building model: LoD3
+
+
+
The semantics and the structure of Buildings, BuildingParts, AbstractBuildings_, BoundarySurfaces_ and BuildingInstallations are identical to the LoD2 case. The more detailed geometry of those features is again represented by a different association names. There is only one semantical concept added in LoD3: BoundarySurface_ objects may have Openings_ (doors and windows) which can be represented as thematic objects with a surface geometry. BuildingInstallations in LoD3 represent dormers, balconies, chimneys or similar objects.
+
+
+
+
D.3.5. Level of Detail 4 (LoD4)
+
+
LoD4 adds detailed interior structures such as rooms, (immovable) interior installations and (movable) building furniture to LoD3 (see Fig. 6d). With respect to the outermost shape of a building, LoD3 and LoD4 are identical. Fig. 14 depicts the UML diagram for LoD4.
+
+
+
+
+
+
+
+
Fig. 12: UML diagram of CityGML’s building model: LoD4
+
+
+
+
+
D.4. Appearance Model
+
+
In addition to spatial and semantical properties, CityGML features have appearances – observable properties of the feature’s surface. Appearances are not limited to visual data (textures showing the visual nature of a facade) but represent arbitrary categories called themes such as infrared radiation, noise pollution, or earthquake-induced structural stress. The UML diagram of CityGML’s appearance model is depicted in Fig. 12.
+
+
+
It is assumed that the image or the observation that is used to represent the material has been mapped properly to the (wall, roof or terrain) surface by using texture mapping methods from computer graphics or photogrammetry.
+
+
+
+
+
+
+
+
Fig. 13: UML diagram of CityGML’s appearance model.
+
+
+
An Appearance object collects surface data either for individual features or the whole city model in any LoD. Surface data is represented by objects of class SurfaceData_. The relation between surface data and surface geometry (e.g., the geometry of a wall of a building) is expressed by an URI (Uniform Resource Identifier) link from a SurfaceData_ object to an object of type gml:AbstractSurfaceType or type gml:MultiSurface. A surface property being constant over the whore surface is modeled as material (class X3DMaterial in the UML diagram). A surface property, which depends on the location within the surface, is modeled as texture. A texture can either be a GeoreferencedTexture or a ParametrizedTexture. The class GeoreferencedTexture describes a texture that uses a planimetric projection. Alternatively, a concept similar to a reference by a world file (e.g. an ESRI world file) can be used. For Parametrized Textures, the mapping from 2D image space to 3D space is achieved either by providing texture coordinates or by applying a 3x4 transformation matrix specified by class TexCoordGen. This matrix defines a linear transformation from a spatial location in homogeneous coordinates to texture space.
+
+
+
Texture coordinates for a surface geometry object are specified using class TexCoordList as a texture parameterization object in the texture’s target property. Each exterior and interior Ring composing the boundary of the target surface geometry object requires its own set of texture coordinates. Fig. 16 illustrates this concept. A TexCoordList contains as many textureCoordinate elements as the target surface geometry object contains gml:LinearRings. The content of a texture coordinate list is an ordered list of double values where each two values defines a image::./media/image285.png[image,width=33,height=23] texture coordinate pair with s denoting the horizontal and t the vertical texture axis. The list contains one pair per ring point with the pairs' order corresponding to the ring points' order.
+
+
+
+
+
+
+
+
Fig. 14: Positioning of textures using texture coordinates: Example
+
+
+
+
D.5. Integration of CityGML into the INSPIRE BU model
+
+
D.5.1. Commonalities between INSPIRE BU model and City GML
+
+
CityGML has strongly influenced the development of the INSPIRE BU model, both for 2D and for 3D profiles.
+
+
+
+
+
The philosophy of base model defining semantical objects, attributes and relations which are required by most applications has been adopted by INSPIRE BU (as core profiles)
+
+
+
The concept of External Reference to enable link to more domain-specific information systems or to ensure consistency between 2D and 3D representations of buildings has also been reused by TWG BU.
+
+
+
The design pattern of Building – BuildingPart aggregation is also included in all the INSPIRE applications schemas
+
+
+
Many attributes (e.g. RoofType, YearOfConstruction) have been included in INSPIRE BU profiles
+
+
+
+
+
Moreover, many use cases that were considered by the INSPIRE BU require a three-dimensional representation of buildings. Examples are noise emission simulation and mapping, solar radiation computation or the design of an infrastructure project. To allow for that, the building representation in LoD1 - LoD4 of CityGML has been added to the INSPIRE BU model as core 3D profile, whereas the whole content of LoD1 - LoD4 (including the features attached to buildings, such as boundaries, openings, rooms, …) are the base of the extended3D profile.
+
+
+
INSPIRE BU model is based on City GML v2.0.
+
+
+
+
D.5.2. Differences between INSPIRE BU model and City GML
+
+
TWG BU has introduced the following changes to City GML:
+
+
+
+
+
City GML has been adapted for INSPIRE:
+
+
+
+
Example 1: the attributes regarding the classification of buildings that are loosely harmonised in City GML (declared as string or code list from German Cadastre given as examples) have been modified/restructured to fit better with the user requirements collected by INSPIRE TWG BU.
+
+
+
Example 2: to ensure cross-theme consistency, the attributes that are common to all INSPIRE themes (identifier, temporal attributes in data set) have received the name and definition supplied by the INSPIRE Generic Conceptual Model rather than the ones supplied by CityGML
+
+
+
+
+
+
CityGML has been simplified for INSPIRE
+
+
+
+
Example 1: in CityGML, the aggregation between Building and BuildingPart is recursive (a part can have parts), whereas in INSPIRE, a part can not have parts (in the CityGML UML diagram, the aggregation starts at AbstractBuilding and is inherited by both Buildings and parts, whereas in INSPIRE, the aggregation starts at Buildings).
+
+
+
Example 2: the model for appearance has been greatly simplified; only the modelling of Parameterized Texture has been kept (because being the only one relevant to model the natural appearance of a building whereas CityGML enables to model also the effect of physical phenomena, such as infrared radiation or noise pollution)
+
+
+
+
+
+
INSPIRE TWG BU has enriched the content of CityGML
+
+
+
Example 1: some feature types (BuildingUnit) and many attributes (e. g. numberOfDwellings, ConditionOfConstruction) have been added to INSPIRE BU model to fulfil the user requirements related to environmental policies, that is the scope of INSPIRE. Typicaly, City GML is about topographic data wheras INSPIRE BU model also includes some official data.
+
+
+
Example 2: in INSPIRE BU model, the geometry is defined as a data type including the geometry itself and some metadata to document it (accuracy, geometry reference) whereas in City GML, the geometry is just provided by geometic primitives, such as GM_Object or GM_MultiSurface
+
+
+
Example 3: in the extended2D/extended3D profiles, the scope of the CityGML model has been extended to include constructions that are not considered as buildings like monuments or antennas.
+
+
+
+
+
+
D.5.3. Mapping between CityGML and INSPIRE BU model
+
+
The following table shows the possible mapping from CityGML data to INSPIRE model for feature type Building.
+
+
+
The mapping would be quite similar for feature type BuildingPart.
+
+
+
+
+
+
+
+
NOTE attributes coloured in green are those coming from Core profiles
+
+
+
References
+
+
+
Cox, S., Lake, R., Portele, C., Whiteside, A., 2003. Geography Markup Language GML 3.1. OGC Doc. No. 03-105r1.
+
+
+
Czerwinski, A., Sandmann, S., Stöcker-Meier, E., Plümer, L., 2007. Sustainable SDI for EU noise mapping in NRW – best practice for INSPIRE. International Journal for Spatial Data Infrastructure Research 2 (1), 90–111.
+
+
+
Gröger, G., Kolbe, T.H., Nagel, C., Häfele, K.-H., 2012. OpenGIS City Geography Markup Language (CityGML) Encoding Standard. Version 2.0.0., Open Geospatial Consortium, OGC Doc. No. 12-019.
+
+
+
Gröger, G., Kolbe, T.H., Czerwinski, A., Nagel, C., 2008. OpenGIS City Geography Markup Language (CityGML) Encoding Standard. Version 1.0.0., Open Geospatial Consortium, OGC Doc. No. 08-007r1.
+
+
+
Gröger, G., Plümer, L., 2012. CityGML - Interoperable semantic 3D City Models. ISPRS Journal of Photogrammetry and Remote Sensing 71 (2012):12-33,
+DOI http://dx.doi.org/10.1016/j.isprsjprs.2012.04.004.
+
+
+
Herring, J., 2001. The OpenGIS Abstract Specification, Topic 1: Feature Geometry (ISO 19107 Spatial Schema). Open Geospatial Consortium, OGC Document Number 01-101, Version 5.
+
+
+
International Organization for Standardization, ISO TC 211, 2003. Geographic information - Metadata (ISO 19115:2003(E)).
+
+
+
International Organization for Standardization, ISO TC 211, 2005. 19109:2005 Geographic information – Rules for application schema (19109:2005(E)).
+
+
+
Kolbe, T.H., Gröger, G., Plümer, L., 2008. CityGML - 3D City Models for Emergency Response. In: Zlatanova, S., Li, J. (Eds.), Geospatial information technology for emergency response. Taylor & Francis, London, pp. 257–274.
+
+
+
Mäntylä, M., 1988. An Introduction to Solid Modeling. Principles of Computer Science. Computer Science Press.
Annex E: Template for additional information - (informative)
+
+
+
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
+
+
+
+
geometry3DLoD1
+
+
geometry3DLoD1
+
+
+
+
geometry3DLoD2
+
+
geometry3DLoD2
+
+
+
+
geometry3DLoD3
+
+
geometry3DLoD3
+
+
+
+
geometry3DLoD4
+
+
geometry3DLoD4
+
+
+
+
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 installations
+
+
association with installations
+
+
+
+
association with building units
+
+
association with building units
+
+
+
+
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
+
+
+
+
+
Extendable code lists
+
+
+
Some code lists in theme BU are extendable. 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: Extension of INSPIRE Buildings model - (informative)
+
+
+
F.1. Introduction - Context
+
+
As a general rule, the INSPIRE application schemas may be extended by data providers, under conditions given in the Generic Conceptual Model, i.e. only if the extension does not break any of the INSPIRE requirements.
+
+
+
This data specification offers two extended profiles, one for 2D (or 2,5D) data and one for 3D data. These extended profiles may and even should be used by data providers, willing to provide more information than the information included in the normative core profiles. For instance, a data provider who wants to replace its current products by INSPIRE themes will have to supply all its data through an INSPIRE conformant model.
+
+
+
The INSPIRE extended profiles may be applied as a whole but also aim 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. The two methods are described in next chapter.
+
+
+
Extended 2D profile includes many concepts coming mainly from cadastral/official information systems. Typically, it is expected that most cadastral/official organisation 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). It concerns for instance building units, official area, official value, address, connections to networks.
+
+
+
For extended profiles both 2D and 3D include also some detailed topographic data (e.g. height and number of floors for the underground part of building, roof type, materials, installations) and even walls, roof, openings, rooms, textures in case of 3D profile; 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 is available until now).
+
+
+
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.
+
+
+
The other extension mechanism relates to the code lists; some INSPIRE code lists are extendable, either "narrower" or "any". Examples of such extensions are provided in last chapter of this annex.
+
+
+
+
F.2. Extension of INSPIRE UML application schema
+
+
F.2.1. Using whole schema
+
+
Data providers may use the extended application schemas provided in this document, either extended 2D or extended 3D profiles.
+
+
+
These INSPIRE application schemas are formal extensions of the core profiles, i.e. they inherit from the application schemas of core profile. The inheritance mechanism ensures that all requirements from core profile have been imported into the extended profile, and so, that the extension has been done respecting the rules given in the Generic Conceptual Model.
+
+
+
Consequently, a data provider supplying its data according to an INSPIRE Buildings extended profile will be automatically conformant to the Implementing Rule related to theme Buildings.
+
+
+
Advantage: the schema is used as it is; so, no modelling effort is required from data provider.
+
+
+
Drawback: data provider and data users have to handle whole extended schema; this may add complexity for data transformation (e.g. dealing with unpopulated features and attributes) and for daily use of data (manipulating a big model).
+
+
+
This option is quite suitable if data provider has a significant ratio of the additional concepts offered by the INSPIRE extended profiles.
+
+
+
+
F.2.2. Using extract of extended schema
+
+
Data providers may define their own extension, by importing (and so inheriting) one of the core profiles and by adding attributes or even features based on the concepts given in the INSPIRE extended profiles, in order to include in this home-made extension only the data they have.
+
+
+
EXAMPLE: A provider of cadastral data wants to supply only additional attributes address and official area as additional elements of core 2D profile. This may be done as shown in figure below.
+
+
+
+
+
+
+
+
Data producer extension importing <Buildings 2D> and using INSPIRE <Buildings Extended2D> concepts.
+
+
+
Data provider must do some modelling effort to design its home-made extended application schema.
+
+
+
Drawback: Data provider must do some modelling effort to design its home-made extended application schema. Data users that expect standardised datasets will need to be able to deal with different schemas, depending on the data producer.
+Advantage: Data providers and data users will only need to deal with a reasonably compact application schema, as the additional parts only include the populated attributes. This option is suitable if data provider has only few extra-content in addition to the core profiles.
+
+
+
+
+
F.3. Extension of INSPIRE code lists
+
+
Some of the code lists included in Buildings application schemas are extendable by Member States ; it is for instance, in core profiles, the case of the code lists regarding classification of Building (CurrentUseValue and BuildingNature).
+
+
+
F.3.1. Hierarchical code list (CurrentUseValue)
+
+
Code list CurrentUseValue 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 related to 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".
+
+
+
+
F.3.2. Other code lists
+
+
The other INSPIRE code lists that are not hierarchical and that are extendable 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 code list for attribute buildingNature might be extended as follow
+
+
+
+
+
…
+
+
+
storageTank
+
+
+
synagogue
+
+
+
temple
+
+
+
tower
+
+
+
+
controlTower
+
+
+
lookoutTower
+
+
+
clockTower
+
+
+
coolingTower
+
+
+
communicationTower
+
+
+
+
+
+
windmill
+
+
+
windTurbine
+
+
+
windmill
+
+
+
kiosk
+
+
+
phoneBooth
+
+
+
busShelter
+
+
+
…
+
+
+
+
+
+
F.3.3. Code lists in extended schemas
+
+
Note that code lists in extended schemas have obligation set to "Technical Guidelines". As the extended application schema itself, the code lists are not normative but only recommendations. Consequently; most of them have also extensibility set to "any"; however, some code lists may have extensibility set to "none" in case extending the code list would break the consistency in the list of possible values. This is typically the case of the code list related to official area and based on the CLGE standard: the code list is not extendable at all but the model offers the possibility to use another code list.
+
+
+
+
+
+
+
+
Annex G: Acknowledgements - (informative)
+
+
+
G.1. 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
+2. 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
+
+4. Surveys on unique identifiers and usage of the elements of the spatial and temporal schema,
+
+
+5. 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 Environment Agency
+
+
+6. 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 Environment Agency
+
+
+7. For Annex IIIII, the consultation and testing phase lasted from 20 June to 21 October 2011.
+
+11. Conceptual models related to specific areas (e.g. INSPIRE themes)
+
+
+12. In the case of the Annex IIIII data specifications, the extracted requirements are used to formulate an amendment to the existing Implementing Rule.
+
+17. Note that for clarity reasons, the geometry in the UML diagrams for LoD0 – LoD4 is represended by attributes. In the specification document, UML classes and relations are used instead. Both representations are equivalent in these cases.
+
+
+18. In LoD4, FloorSurface, InteriorWallSurface, and CeilingSurface are provided in addition.
+
+
+
+
\ No newline at end of file
diff --git a/data/bu/dataspecification_bu.pdf b/data/bu/dataspecification_bu.pdf
new file mode 100644
index 00000000..8c0e34a1
Binary files /dev/null and b/data/bu/dataspecification_bu.pdf differ
diff --git a/data/ef/dataspecification_ef.html b/data/ef/dataspecification_ef.html
index 7ab4c3c3..3619dd1f 100644
--- a/data/ef/dataspecification_ef.html
+++ b/data/ef/dataspecification_ef.html
@@ -465,7 +465,7 @@
For the exchange and classification of spatial objects from data sets meeting the conditions laid down in Article 4 of Directive 2007/2/EC, Member States shall use the spatial object types and associated data types, enumerations and code lists that are defined in Annexes II, III and IV for the themes the data sets relate to.
-
-
-
Spatial object types and data types shall comply with the definitions and constraints and include the attributes and association roles set out in the Annexes.
+
For the exchange and classification of spatial objects from data sets meeting the conditions laid down in Article 4 of Directive 2007/2/EC, Member States shall use the spatial object types and associated data types and code lists that are defined in Annexes II, III and IV for the themes the data sets relate to.
-
The enumerations and code lists used in attributes or association roles of spatial object types or data types shall comply with the definitions and include the values set out in Annex II. The enumeration and code list values are uniquely identified by language-neutral mnemonic codes for computers. The values may also include a language-specific name to be used for human interaction.
+
When exchanging spatial objects, Member States shall comply with the definitions and constraints set out in the Annexes and provide values for all attributes and association roles set out for the relevant spatial object types and data types in the Annexes. For voidable attributes and association roles for which no value exists, Member States may omit the value.
@@ -1676,11 +1672,6 @@
5.2.1.2. Stereotypes
A structured data type without identity where exactly one of the properties of the type is present in any instance.
-
enumeration
-
Class
-
An enumeration.
-
-
codeList
Class
A code list.
@@ -1774,54 +1765,12 @@
5.2.2. Voidable characteristics
-
5.2.3. 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
-Article 6
-Code Lists and Enumerations
-
-
-
(…)
-
-
-
-
-
Attributes or association roles of spatial object types or data types that have an enumeration type may only take values from the lists specified for the enumeration type."
-
-
-
-
-
-
-
-
-
-
5.2.4. Code lists
+
5.2.3. Code lists
Code lists are modelled as classes in the application schemas. Their values, however, are managed outside of the application schema.
-
5.2.4.1. Code list types
+
5.2.3.1. Code list types
The IRs distinguish the following types of code lists.
@@ -1835,32 +1784,44 @@
5.2.4.1. Code list types
IR Requirement Article 6
-Code Lists and Enumerations
+Code Lists for Spatial Data Sets
-
+
+
+
The code lists included in this Regulation set out the multilingual thesauri to be used for the key attributes, in accordance with Article 8(2), point (c), of Directive 2007/2/EC.
+
+
+
The Commission shall establish and operate an INSPIRE code list register at Union level for managing and making publicly available the values that are included in the code lists referred to in paragraph 1.
+
+
+
The Commission shall be assisted by the INSPIRE Commission expert group in the maintenance and update of the code list values.
+
-
Code lists shall be of one of the following types, as specified in the Annexes:
+
Code lists shall be one of the following types:
-
code lists whose allowed values comprise only the values specified in this Regulation;
+
code lists whose values comprise only the values specified in the INSPIRE code list register;
-
code lists whose allowed values comprise the values specified in this Regulation and narrower values defined by data providers;
+
code lists whose values comprise the values specified in the INSPIRE code list register and narrower values defined by data providers;
-
code lists whose allowed values comprise the values specified in this Regulation and additional values at any level defined by data providers;
+
code lists whose values comprise the values specified in the INSPIRE code list register and additional values at any level defined by data providers;
-
code lists, whose allowed values comprise any values defined by data providers.
-
-
For the purposes of points (b), (c) and (d), in addition to the allowed values, data providers may use the values specified in the relevant INSPIRE Technical Guidance document available on the INSPIRE web site of the Joint Research Centre.
-
+
code lists, whose values comprise any values defined by data providers.
+
+
Code lists may be hierarchical. Values of hierarchical code lists may have a more general parent value.
+
+
+
Where, for an attribute whose type is a code list as referred to in paragraph 4, points (b), (c) or (d), a data provider provides a value that is not specified in the INSPIRE code list register, that value and its definition and label shall be made available in another register.
+
@@ -1919,15 +1880,15 @@
5.2.4.1. Code list types
IR Requirement Article 6
-Code Lists and Enumerations
+Code Lists for Spatial Data Sets
(…)
-
+
-
Code lists may be hierarchical. Values of hierarchical code lists may have a more generic parent value. Where the valid values of a hierarchical code list are specified in a table in this Regulation, the parent values are listed in the last column.
+
Code lists may be hierarchical. Values of hierarchical code lists may have a more generic parent value.
@@ -1940,7 +1901,7 @@
5.2.4.1. Code list types
-
5.2.4.2. Obligations on data providers
+
5.2.3.2. Obligations on data providers
@@ -1951,18 +1912,15 @@
5.2.4.2. Obligations on data providers
IR Requirement Article 6
-Code Lists and Enumerations
+Code Lists for Spatial Data Sets
(….)
-
+
-
Where, for an attribute whose type is a code list as referred to in points (b), (c) or (d) of paragraph 1, a data provider provides a value that is not specified in this Regulation, that value and its definition shall be made available in a register.
-
-
-
Attributes or association roles of spatial object types or data types whose type is a code list may only take values that are allowed according to the specification of the code list.
+
Where, for an attribute whose type is a code list as referred to in paragraph 4, points (b), (c) or (d), a data provider provides a value that is not specified in the INSPIRE code list register, that value and its definition and label shall be made available in another register.
@@ -1971,17 +1929,17 @@
5.2.4.2. Obligations on data providers
-
Article 6(4) obliges data providers to use only values that are allowed according to the specification of the code list. The "allowed values according to the specification of the code list" are the values explicitly defined in the IRs plus (in the case of code lists of type (b), (c) and (d)) additional values defined by data providers.
+
Article 6(6) obliges data providers to use only values that are allowed according to the specification of the code list. The "allowed values according to the specification of the code list" are the values explicitly defined in the IRs plus (in the case of code lists of type (b), (c) and (d)) additional values defined by data providers.
-
For attributes whose type is a code list of type (b), (c) or (d) data providers may use additional values that are not defined in the IRs. Article 6(3) requires that such additional values and their definition be made available in a register. This enables users of the data to look up the meaning of the additional values used in a data set, and also facilitates the re-use of additional values by other data providers (potentially across Member States).
+
For attributes whose type is a code list of type (b), (c) or (d) data providers may use additional values that are not defined in the IRs. Article 6(6) requires that such additional values and their definition be made available in a register. This enables users of the data to look up the meaning of the additional values used in a data set, and also facilitates the re-use of additional values by other data providers (potentially across Member States).
NOTE Guidelines for setting up registers for additional values and how to register additional values in these registers is still an open discussion point between Member States and the Commission.
-
5.2.4.3. Recommended code list values
+
5.2.3.3. Recommended code list values
For code lists of type (b), (c) and (d), this data specification may propose additional values as a recommendation (in a dedicated Annex). These values will be included in the INSPIRE code list register. This will facilitate and encourage the usage of the recommended values by data providers since the obligation to make additional values defined by data providers available in a register (see section 5.2.4.2) is already met.
@@ -2007,7 +1965,7 @@
5.2.4.3. Recommended code list values
-
5.2.4.4. Governance
+
5.2.3.4. Governance
The following two types of code lists are distinguished in INSPIRE:
@@ -2071,7 +2029,7 @@
5.2.4.4. Governance
-
5.2.4.5. Vocabulary
+
5.2.3.5. Vocabulary
For each code list, a tagged value called "vocabulary" is specified to define a URI identifying the values of the code list. For INSPIRE-governed code lists and externally governed code lists that do not have a persistent identifier, the URI is constructed following the pattern http://inspire.ec.europa.eu/codelist/<UpperCamelCaseName>;.
@@ -2084,7 +2042,7 @@
5.2.4.5. Vocabulary
-
5.2.5. Identifier management
+
5.2.4. Identifier management
@@ -2122,7 +2080,7 @@
5.2.5. Identifier management
-
5.2.6. Geometry representation
+
5.2.5. Geometry representation
@@ -2154,7 +2112,7 @@
5.2.6. Geometry representation
-
5.2.7. Temporality representation
+
5.2.6. Temporality representation
The application schema(s) use(s) the derived attributes "beginLifespanVersion" and "endLifespanVersion" to record the lifespan of a spatial object.
@@ -2214,7 +2172,7 @@
5.2.7. Temporality representation
-
5.2.7.1. Validity of the real-world phenomena
+
5.2.6.1. Validity of the real-world phenomena
The application schema(s) use(s) the attributes "validFrom" and "validTo" to record the validity of the real-world phenomenon represented by a spatial object.
@@ -2256,7 +2214,7 @@
5.2.7.1. Validity of the real-wor
-
5.2.8. Coverages
+
5.2.7. 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. isolines), grids (e.g. orthoimages, elevation models), etc.
@@ -2526,10 +2484,10 @@
5.3.2. Feature catalogue
Feature catalogue metadata
-
+
-
-
+
+
@@ -2841,6 +2799,35 @@
5.3.2.1.2. AbstractMonitoringObject<
+
Attribute: thematicId
+
+
+
+
+
+
+
+
+
Value type:
+
ThematicIdentifier
+
+
+
Definition:
+
Thematic object identifier.
+
+
+
Multiplicity:
+
0..*
+
+
+
Stereotypes:
+
«voidable»
+
+
+
+
+
+
Attribute: name
@@ -4597,7 +4584,7 @@
5.3.2.3.1. MeasurementRegimeValue
Values:
-
The allowed values for this code list comprise any values defined by data providers. Annex C includes recommended values that may be used by data providers.
+
The allowed values for this code list comprise any values defined by data providers. INSPIRE Registry includes recommended values that may be used by data providers.
@@ -4642,7 +4629,7 @@
5.3.2.3.2. MediaValue
Values:
-
The allowed values for this code list comprise any values defined by data providers. Annex C includes recommended values that may be used by data providers.
+
The allowed values for this code list comprise any values defined by data providers. INSPIRE Registry includes recommended values that may be used by data providers.
@@ -4687,7 +4674,7 @@
5.3.2.3.3. ProcessTypeValue
Values:
-
The allowed values for this code list comprise any values defined by data providers. Annex C includes recommended values that may be used by data providers.
+
The allowed values for this code list comprise any values defined by data providers. INSPIRE Registry includes recommended values that may be used by data providers.
@@ -4732,7 +4719,7 @@
5.3.2.3.4. PurposeOfCollectionValue<
Values:
-
The allowed values for this code list comprise any values defined by data providers. Annex C includes recommended values that may be used by data providers.
+
The allowed values for this code list comprise any values defined by data providers. INSPIRE Registry includes recommended values that may be used by data providers.
@@ -4777,7 +4764,7 @@
5.3.2.3.5. ResultAcquisitionSourceVal
Values:
-
The allowed values for this code list comprise any values defined by data providers. Annex C includes recommended values that may be used by data providers.
+
The allowed values for this code list comprise any values defined by data providers. INSPIRE Registry includes recommended values that may be used by data providers.
@@ -4822,7 +4809,7 @@
5.3.2.3.6. ResultNatureValue
Values:
-
The allowed values for this code list comprise any values defined by data providers. Annex C includes recommended values that may be used by data providers.
+
The allowed values for this code list comprise any values defined by data providers. INSPIRE Registry includes recommended values that may be used by data providers.
@@ -4867,7 +4854,7 @@
5.3.2.3.7. SpecialisedEMFTypeValue
Values:
-
The allowed values for this code list comprise any values defined by data providers. Annex C includes recommended values that may be used by data providers.
+
The allowed values for this code list comprise any values defined by data providers. INSPIRE Registry includes recommended values that may be used by data providers.
@@ -4879,7 +4866,7 @@
5.3.2.3.7. SpecialisedEMFTypeValue
5.3.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.
+
This section lists definitions for feature types, data types and code lists that are defined in other application schemas. The section is purely informative and should help the reader understand the feature catalogue presented in the previous sections. For the normative documentation of these types, see the given references.
5.3.2.4.1. Boolean
@@ -5537,7 +5524,7 @@
6.1.1.2. Coordinate reference systems
-
Other coordinate reference systems may be specified for specific spatial data themes in this Annex.
+
Other coordinate reference systems may be specified for specific spatial data themes.
For regions outside of continental Europe, Member States may define suitable coordinate reference systems.
@@ -5545,7 +5532,8 @@
6.1.1.2. Coordinate reference systems
-
The geodetic codes and parameters needed to describe these coordinate reference systems and to allow conversion and transformation operations shall be documented and an identifier shall be created, according to EN ISO 19111 and ISO 19127.
+
The geodetic codes and parameters needed to describe these other coordinate reference systems and to allow conversion and transformation operations shall be documented and an identifier shall be created in a coordinate systems register established and operated by the Commission, according to EN ISO 19111 and ISO 19127.
+The Commission shall be assisted by the INSPIRE Commission expert group in the maintenance and update of the coordinate systems register.
@@ -5585,7 +5573,7 @@
6.1.1.4. Identifiers for
IR Requirement
-Annex II, Section 1.4
+Annex II, Section 1.5 Coordinate Reference Systems used in the View Network Service
@@ -5603,7 +5591,7 @@
6.1.1.4. Identifiers for
-
This Technical Guidelines proposes to use the http URIs provided by the Open Geospatial Consortium as coordinate reference system identifiers (see identifiers for the default CRSs below). These are based on and redirect to the definition in the EPSG Geodetic Parameter Registry (http://www.epsg-registry.org/).
+
This Technical Guidelines proposes to use the http URIs provided by the Open Geospatial Consortium as coordinate reference system identifiers (see identifiers for the default CRSs in the INSPIRE coordinate reference systems register). These are based on and redirect to the definition in the EPSG Geodetic Parameter Registry (http://www.epsg-registry.org/).
@@ -5616,7 +5604,7 @@
6.1.1.4. Identifiers for
TG Requirement 2
-
The identifiers listed in Table 2 shall be used for referring to the coordinate reference systems used in a data set.
+
The identifiers listed in the INSPIRE coordinate reference systems register (https://inspire.ec.europa.eu/crs) shall be used for referring to the coordinate reference systems used in a data set.
@@ -5638,130 +5626,6 @@
6.1.1.4. Identifiers for
-
-
Table 2. http URIs for the default coordinate reference systems
8.3.2.1. Guidelines for reporting quantitative results of the data quality evaluation
-
+
-
-
+
+
@@ -7528,10 +7392,10 @@
8.3.2.2. Guidelines for reporting descriptive results of the Data Quality evaluation
-
+
-
-
+
+
@@ -7615,10 +7479,10 @@
8.3.3. Keyword
-
+
-
-
+
+
@@ -7800,15 +7664,14 @@
9.3. Encodings
Article 7 Encoding
-
-
-
-
Every encoding rule used to encode spatial data shall conform to EN ISO 19118. In particular, it shall specify schema conversion rules for all spatial object types and all attributes and association roles and the output data structure used.
-
-
-
Every encoding rule used to encode spatial data shall be made available.
-
-
+
+
1. Every encoding rule used to encode spatial data shall conform to EN ISO 19118. In particular, it shall specify schema conversion rules for all spatial object types and all attributes and association roles and the output data structure used.
+
+
+
2. Every encoding rule used to encode spatial data shall be made available.
+
+
+
2a. Every encoding rule used to encode spatial data shall also specify whether and how to represent attributes and association roles for which a corresponding value exists but is not contained in the spatial data sets maintained by a Member State, or cannot be derived from existing values at reasonable costs.
@@ -8230,10 +8093,10 @@
11.1.1. Layers organisation
11.2. Styles required to be supported by INSPIRE view services
11.2.1. Styles for the layer EF.EnvironmentalMonitoringFacilities
-
+
-
-
+
+
@@ -8401,10 +8264,10 @@
11.2.1. Styl
11.2.2. Styles for the layer EF.EnvironmentalMonitoringNetworks
-
+
-
-
+
+
@@ -8543,10 +8406,10 @@
11.2.2. Styles
11.2.3. Styles for the layer EF.EnvironmentalMonitoringProgrammes
-
+
-
-
+
+
@@ -9034,7 +8897,7 @@
Annex A: Abstract Test Suite -(normative
all the spatial object / data types that have corresponding types in the source dataset after the necessary transformations fulfil the requirements set out in the ISDSS Regulation and
-
all additional elements of the source model (spatial object types, data types, attributes, constraints, code lists and enumerations together with their values) do not conflict with any rule defined in the interoperability target specifications defined for any theme within INSPIRE.
+
all additional elements of the source model (spatial object types, data types, attributes, constraints and code lists together with their values) do not conflict with any rule defined in the interoperability target specifications defined for any theme within INSPIRE.
@@ -9092,7 +8955,7 @@
A.1.1. Schema element denomination te
b) Reference: Art. 3 and Art.4 of Commission Regulation No 1089/2010
-
c) Test Method: Examine whether the corresponding elements of the source schema (spatial object types, data types, attributes, association roles, code lists, and enumerations) are mapped to the target schema with the correct designation of mnemonic names.
+
c) Test Method: Examine whether the corresponding elements of the source schema (spatial object types, data types, attributes, association roles and code lists) are mapped to the target schema with the correct designation of mnemonic names.
NOTE Further technical information is in the Feature catalogue and UML diagram of the application schema(s) in section 5.2.
@@ -9110,7 +8973,7 @@
A.1.2. Value type test
c) Test Method: Examine whether the value type of each provided attribute or association role adheres to the corresponding value type specified in the target specification.
-
NOTE 1 This test comprises testing the value types of INSPIRE identifiers, the value types of attributes and association roles that should be taken from enumeration and code lists, and the coverage domains.
+
NOTE 1 This test comprises testing the value types of INSPIRE identifiers, the value types of attributes and association roles that should be taken from code lists, and the coverage domains.
NOTE 2 Further technical information is in the Feature catalogue and UML diagram of the application schema(s) in section 5.2.
@@ -9119,20 +8982,17 @@
A.1.2. Value type test
A.1.3. Value test
-
a) Purpose: Verify whether all attributes or association roles whose value type is a code list or enumeration take the values set out therein.
+
a) Purpose: Verify whether all attributes or association roles whose value type is a code list take the values set out therein.
b) Reference: Art.4 (3) of Commission Regulation No 1089/2010.
-
c) Test Method: When an attribute / association role has an enumeration or code list as its type, compare the values of each instance with those provided in the application schema. To pass this tests any instance of an attribute / association role
+
c) Test Method: When an attribute / association role has an code list as its type, compare the values of each instance with those provided in the application schema. To pass this tests any instance of an attribute / association role
-
shall not take any other value than defined in the enumeration table when its type is an enumeration.
-
-
shall take only values explicitly specified in the code list when the code list’s extensibility is "none".
@@ -9673,7 +9533,7 @@
A.9.2. CRS http URI test
a) Purpose: Verify whether the coordinate reference system used to deliver data for INSPIRE network services has been identified by URIs according to the EPSG register.
-
b) Reference: Table 2 in Section 6 of this technical guideline
+
b) Reference: Section 6 of this technical guideline
c) Test Method: Compare the URI of the dataset with the URIs in the table.
@@ -11277,10 +11137,10 @@
Annex C: Code list values - (normative)
-
+
-
-
+
+
@@ -11303,7 +11163,7 @@
Annex C: Code list values - (normative)
Values:
-
+
The INSPIRE Registry includes recommended values that may be used by data providers.
@@ -11311,7 +11171,7 @@
Annex C: Code list values - (normative)
-
The table below includes recommended values that may be used by data providers.
+
MediaValue
@@ -11319,294 +11179,65 @@
Annex C: Code list values - (normative)
-
-
continuousDataCollection
-
-
+
-
-
+
+
-
+
-
Name:
-
continuous data collection
+
Name:
+
media
+
+
Definition:
-
Data is collected on a continuous basis. there is usually no end date, as further data is collected
The table below includes recommended values that may be used by data providers.
-
-
-
-
-
-
-
-
-
air
-
-
-
-
-
-
-
-
-
Name:
-
air
-
-
-
-
-
-
-
biota
-
-
-
-
-
-
-
-
-
Name:
-
biota
-
-
-
-
-
-
-
landscape
-
-
-
-
-
-
-
-
-
Name:
-
landscape
-
-
-
-
-
-
-
sediment
-
-
-
-
-
-
-
-
-
Name:
-
sediment
-
-
-
-
-
-
-
soil/ground
-
-
-
-
-
-
-
-
-
Name:
-
soil/ground
-
-
-
-
-
-
-
waste
-
-
-
-
-
-
-
-
-
Name:
-
waste
-
-
-
-
-
-
-
water
-
-
-
-
-
-
-
-
-
Name:
-
water
-
-
-
-
-
-
-
-
ProcessTypeValue
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Name:
-
process type
-
-
-
Definition:
-
Categories for different process types.
-
-
-
Extensibility:
-
any
+
+
Extensibility:
+
any
Identifier:
@@ -11614,59 +11245,7 @@
Annex C: Code list values - (normative)
Values:
-
-
-
-
-
-
-
-
-
The table below includes recommended values that may be used by data providers.
-
-
-
-
-
-
-
-
-
process
-
-
-
-
-
-
-
-
-
Name:
-
Process
-
-
-
Definition:
-
Indicates that the class used for the description of methodological information of the Observation (ProcessUsed association) is the Process class defined in the GCM.
-
-
-
-
-
-
-
sensorML
-
-
-
-
-
-
-
-
-
Name:
-
SensorML
-
-
-
Definition:
-
Indicates that the class used for the description of methodological information of the Observation (ProcessUsed association) comes from SensorML.
+
The INSPIRE Registry includes recommended values that may be used by data providers.
@@ -11682,10 +11261,10 @@
Annex C: Code list values - (normative)
-
+
-
-
+
+
@@ -11708,101 +11287,7 @@
Annex C: Code list values - (normative)
Values:
-
-
-
-
-
-
-
-
-
The table below includes recommended values that may be used by data providers.
-
-
-
-
-
-
-
-
-
exSitu
-
-
-
-
-
-
-
-
-
Name:
-
ex-situ
-
-
-
Definition:
-
The FeatureOfInterest is a specimen taken from the ultimate FeatureOfInterest (i.e. the sampledFeature).
-
-
-
-
-
-
-
inSitu
-
-
-
-
-
-
-
-
-
Name:
-
in-situ
-
-
-
Definition:
-
The FeatureOfInterest is a sampling feature which is co-located with the ultimate FeatureOfInterest (i.e. the sampledFeature).
-
-
-
-
-
-
-
remoteSensing
-
-
-
-
-
-
-
-
-
Name:
-
remote-sensing
-
-
-
Definition:
-
The FeatureOfInterest is a sampling feature which is also the ultimate FeatureOfInterest (i.e. the sampledFeature).
-
-
-
-
-
-
-
subsumed
-
-
-
-
-
-
-
-
-
Name:
-
subsumed
-
-
-
Definition:
-
The value is inherited from children.
+
The INSPIRE Registry includes recommended values that may be used by data providers.
@@ -11818,10 +11303,10 @@
Annex C: Code list values - (normative)
-
+
-
-
+
+
@@ -11844,80 +11329,7 @@
Annex C: Code list values - (normative)
Values:
-
-
-
-
-
-
-
-
-
The table below includes recommended values that may be used by data providers.
-
-
-
-
-
-
-
-
-
primary
-
-
-
-
-
-
-
-
-
Name:
-
primary
-
-
-
Definition:
-
The result provided with the observation is the direct result of an estimate of a property on the featureOfInterest. No further processing has been performed. Processing may have taken place, but only in the sense of the measurement methodology itself, i.e. converting the millivolt returned from the sensor to the concentration of a substance.
-
-
-
-
-
-
-
processed
-
-
-
-
-
-
-
-
-
Name:
-
processed
-
-
-
Definition:
-
The result provided, while usually based on primary measurements, has been substantially processed. This processing can be of diverse natures, in some situations complex aggregates are provided, in other situations, the existing values are interpolated to a continuum.
-
-
-
-
-
-
-
simulated
-
-
-
-
-
-
-
-
-
Name:
-
simulated
-
-
-
Definition:
-
The result provided, while usually based on primary measurements, is based on an interpretation model, and provides a simulation of past or future states of the media being analyzed. In this case, the existing values are usually extrapolated into the past or future.
+
The INSPIRE Registry includes recommended values that may be used by data providers.
diff --git a/data/ef/dataspecification_ef.pdf b/data/ef/dataspecification_ef.pdf
index db1944ba..5c5a34b7 100644
Binary files a/data/ef/dataspecification_ef.pdf and b/data/ef/dataspecification_ef.pdf differ
diff --git a/data/el/dataspecification_el.html b/data/el/dataspecification_el.html
index f2ad00a7..666f23c3 100644
--- a/data/el/dataspecification_el.html
+++ b/data/el/dataspecification_el.html
@@ -466,7 +466,7 @@
In the case of the vector model, this data specification allows the use of 2-D or 2.5-D geometries. In the first case the vertical component of the coordinates are given as an attribute of a two dimensional spatial object, while in the second all the points in the elevation data set are expressed using three coordinates, where the elevation value is assigned to the (third) Z coordinate.
-
In line with existing technologies three spatial representation methods have been offered: grid, of mandatory provision, as well as vector and triangulated irregular network (TIN), of optional provision. Each of them is described in a separate package. In addition, generic modelling elements, such as enumerations and generic utilities (data types) are included in the base types application schema.
+
In line with existing technologies three spatial representation methods have been offered: grid, of mandatory provision, as well as vector and triangulated irregular network (TIN), of optional provision. Each of them is described in a separate package. In addition, generic modelling elements, such generic utilities (data types) are included in the base types application schema.
The Elevation data specification includes the widely used grid representation, which is based on a coverage geometry, indicating elevation values at the points of a rectified grid. For Pan-European and cross-border purposes the data specification recommends the provision of elevation data using a theme-specific common grid based on ETRS89 geodetic coordinates (shared with the Orthoimagery data specifications), while using real time re-projection for display through view services.
IR Requirement
-Article 4
+Article 4 Types for the Exchange and Classification of Spatial Objects
-
For the exchange and classification of spatial objects from data sets meeting the conditions laid down in Article 4 of Directive 2007/2/EC, Member States shall use the spatial object types and associated data types, enumerations and code lists that are defined in Annexes II, III and IV for the themes the data sets relate to.
+
For the exchange and classification of spatial objects from data sets meeting the conditions laid down in Article 4 of Directive 2007/2/EC, Member States shall use the spatial object types and associated data types and code lists that are defined in Annexes II, III and IV for the themes the data sets relate to.
-
Spatial object types and data types shall comply with the definitions and constraints and include the attributes and association roles set out in the Annexes.
-
-
-
The enumerations and code lists used in attributes or association roles of spatial object types or data types shall comply with the definitions and include the values set out in Annex II. The enumeration and code list values are uniquely identified by language-neutral mnemonic codes for computers. The values may also include a language-specific name to be used for human interaction.
+
When exchanging spatial objects, Member States shall comply with the definitions and constraints set out in the Annexes and provide values for all attributes and association roles set out for the relevant spatial object types and data types in the Annexes. For voidable attributes and association roles for which no value exists, Member States may omit the value.
@@ -1774,7 +1770,7 @@
5.1.1. Application schemas inc
-
The ElevationBaseTypes application schema, which provides basic enumerations for the rest application schemas of Elevation (Section 5.4).
+
The ElevationBaseTypes application schema, which provides basic codelists for the rest application schemas of Elevation (Section 5.4).
The ElevationGridCoverage application schema, which defines the model for Elevation data in the grid spatial representation type (Section 5.5).
@@ -1945,11 +1941,6 @@
5.2.1.2. Stereotypes
A structured data type without identity where exactly one of the properties of the type is present in any instance.
-
enumeration
-
Class
-
An enumeration.
-
-
codeList
Class
A code list.
@@ -2043,48 +2034,12 @@
5.2.2. Voidable characteristics
-
5.2.3. 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
-Article 6
-Code Lists and Enumerations
-(…)
-
-
-
5) Attributes or association roles of spatial object types or data types that have an enumeration type may only take values from the lists specified for the enumeration type."
-
-
-
-
-
-
-
-
5.2.4. Code lists
+
5.2.3. Code lists
Code lists are modelled as classes in the application schemas. Their values, however, are managed outside of the application schema.
-
5.2.4.1. Code list types
+
5.2.3.1. Code list types
The IRs distinguish the following types of code lists.
@@ -2097,22 +2052,46 @@
5.2.4.1. Code list types
IR Requirement
-Article 6
-Code Lists and Enumerations
+Article 6
+Code Lists for Spatial Data Sets
-
Code lists shall be of one of the following types, as specified in the Annexes:
-a) code lists whose allowed values comprise only the values specified in this Regulation;
-b) code lists whose allowed values comprise the values specified in this Regulation and narrower values defined by data providers;
-c) code lists whose allowed values comprise the values specified in this Regulation and additional values at any level defined by data providers;
-d) code lists, whose allowed values comprise any values defined by data providers.
+
The code lists included in this Regulation set out the multilingual thesauri to be used for the key attributes, in accordance with Article 8(2), point (c), of Directive 2007/2/EC.
+
+
+
The Commission shall establish and operate an INSPIRE code list register at Union level for managing and making publicly available the values that are included in the code lists referred to in paragraph 1.
+
+
+
The Commission shall be assisted by the INSPIRE Commission expert group in the maintenance and update of the code list values.
+
+
+
Code lists shall be one of the following types:
+
+
+
+
code lists whose values comprise only the values specified in the INSPIRE code list register;
+
+
+
code lists whose values comprise the values specified in the INSPIRE code list register and narrower values defined by data providers;
+
+
+
code lists whose values comprise the values specified in the INSPIRE code list register and additional values at any level defined by data providers;
+
+
+
code lists, whose values comprise any values defined by data providers.
-
-
For the purposes of points (b), (c) and (d), in addition to the allowed values, data providers may use the values specified in the relevant INSPIRE Technical Guidance document available on the INSPIRE web site of the Joint Research Centre.
+
+
+
Code lists may be hierarchical. Values of hierarchical code lists may have a more general parent value.
+
+
+
Where, for an attribute whose type is a code list as referred to in paragraph 4, points (b), (c) or (d), a data provider provides a value that is not specified in the INSPIRE code list register, that value and its definition and label shall be made available in another register.
+
+
@@ -2158,7 +2137,7 @@
5.2.4.1. Code list types
NOTE This data specification may specify recommended values for some of the code lists of type (b), (c) and (d) (see section 5.2.4.3). These recommended values are specified in a dedicated Annex.
-
In addition, code lists can be hierarchical, as explained in Article 6(2) of the IRs.
+
In addition, code lists can be hierarchical, as explained in Article 6(5) of the IRs.
@@ -2169,12 +2148,18 @@
5.2.4.1. Code list types
IR Requirement
-Article 6
-Code Lists and Enumerations
-(…)
+Article 6
+Code Lists for Spatial Data Sets
-
2) Code lists may be hierarchical. Values of hierarchical code lists may have a more generic parent value. Where the valid values of a hierarchical code list are specified in a table in this Regulation, the parent values are listed in the last column.
+
(…)
+
+
+
+
+
Code lists may be hierarchical. Values of hierarchical code lists may have a more generic parent value. Where the valid values of a hierarchical code list are specified in a table in this Regulation, the parent values are listed in the last column.
+
+
@@ -2185,7 +2170,7 @@
5.2.4.1. Code list types
-
5.2.4.2. Obligations on data providers
+
5.2.3.2. Obligations on data providers
@@ -2195,32 +2180,35 @@
5.2.4.2. Obligations on data providers
IR Requirement
-Article 6
-Code Lists and Enumerations
-(….)
+Article 6
+Code Lists for Spatial Data Sets
-
3) Where, for an attribute whose type is a code list as referred to in points (b), (c) or (d) of paragraph 1, a data provider provides a value that is not specified in this Regulation, that value and its definition shall be made available in a register.
+
(….)
-
-
4) Attributes or association roles of spatial object types or data types whose type is a code list may only take values that are allowed according to the specification of the code list.
+
+
+
+
Where, for an attribute whose type is a code list as referred to in points (b), (c) or (d) of paragraph 1, a data provider provides a value that is not specified in this Regulation, that value and its definition shall be made available in a register.
+
+
-
Article 6(4) obliges data providers to use only values that are allowed according to the specification of the code list. The "allowed values according to the specification of the code list" are the values explicitly defined in the IRs plus (in the case of code lists of type (b), (c) and (d)) additional values defined by data providers.
+
Article 6(6) obliges data providers to use only values that are allowed according to the specification of the code list. The "allowed values according to the specification of the code list" are the values explicitly defined in the IRs plus (in the case of code lists of type (b), (c) and (d)) additional values defined by data providers.
-
For attributes whose type is a code list of type (b), (c) or (d) data providers may use additional values that are not defined in the IRs. Article 6(3) requires that such additional values and their definition be made available in a register. This enables users of the data to look up the meaning of the additional values used in a data set, and also facilitates the re-use of additional values by other data providers (potentially across Member States).
+
For attributes whose type is a code list of type (b), (c) or (d) data providers may use additional values that are not defined in the IRs. Article 6(6) requires that such additional values and their definition be made available in a register. This enables users of the data to look up the meaning of the additional values used in a data set, and also facilitates the re-use of additional values by other data providers (potentially across Member States).
NOTE Guidelines for setting up registers for additional values and how to register additional values in these registers is still an open discussion point between Member States and the Commission.
-
5.2.4.3. Recommended code list values
+
5.2.3.3. Recommended code list values
For code lists of type (b), (c) and (d), this data specification may propose additional values as a recommendation (in a dedicated Annex). These values will be included in the INSPIRE code list register. This will facilitate and encourage the usage of the recommended values by data providers since the obligation to make additional values defined by data providers available in a register (see section 5.2.4.2) is already met.
@@ -2246,7 +2234,7 @@
5.2.4.3. Recommended code list values
-
5.2.4.4. Governance
+
5.2.3.4. Governance
The following two types of code lists are distinguished in INSPIRE:
@@ -2254,19 +2242,12 @@
5.2.4.4. Governance
Code lists that are governed by INSPIRE (INSPIRE-governed code lists). These code lists will be managed centrally in the INSPIRE code list register. Change requests to these code lists (e.g. to add, deprecate or supersede values) are processed and decided upon using the INSPIRE code list register’s maintenance workflows.
-
-
-
-
-
INSPIRE-governed code lists will be made available in the INSPIRE code list register at http://inspire.ec.europa.eu/codelist/<CodeListName>. They will be available in SKOS/RDF, XML and HTML. The maintenance will follow the procedures defined in ISO 19135. This means that the only allowed changes to a code list are the addition, deprecation or supersession of values, i.e. no value will ever be deleted, but only receive different statuses (valid, deprecated, superseded). Identifiers for values of INSPIRE-governed code lists are constructed using the pattern http://inspire.ec.europa.eu/codelist/<CodeListName>/<value>.
-
-
-
+
+
Code lists that are governed by an organisation outside of INSPIRE (externally governed code lists). These code lists are managed by an organisation outside of INSPIRE, e.g. the World Meteorological Organization (WMO) or the World Health Organization (WHO). Change requests to these code lists follow the maintenance workflows defined by the maintaining organisations. Note that in some cases, no such workflows may be formally defined.
-
@@ -2280,11 +2261,6 @@
5.2.4.4. Governance
The Source column specifies a citation for the authoritative source for the values of the code list. For code lists, whose values are mandated in the IRs, this citation should include the version of the code list used in INSPIRE. The version can be specified using a version number or the publication date. For code list values recommended in these Technical Guidelines, the citation may refer to the "latest available version".
-
-
-
-
-
In some cases, for INSPIRE only a subset of an externally governed code list is relevant. The subset is specified using the Subset column.
@@ -2297,13 +2273,14 @@
5.2.4.4. Governance
-
The http URIs and labels used for encoding code list values should be taken from the INSPIRE code list registry for INSPIRE-governed code lists and generated according to the relevant rules specified for externally governed code lists.
-NOTE Where practicable, the INSPIRE code list register could also provide http URIs and labels for externally governed code lists.
+
The http URIs and labels used for encoding code list values should be taken from the INSPIRE code list registry for INSPIRE-governed code lists and generated according to the relevant rules specified for externally governed code lists.
+
+
NOTE Where practicable, the INSPIRE code list register could also provide http URIs and labels for externally governed code lists.
+
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>;.
@@ -2318,12 +2295,13 @@
5.2.4.4. Governance
-
+
+
-
5.2.5. Consistency between spatial data sets
+
5.2.4. Consistency between spatial data sets
This section specifies generic consistency rules which are applicable to all Elevation application schemas.
@@ -2347,13 +2325,13 @@
5.2.5. Consistency between spati
Several of these topic areas affect the consistency of elevation data itself and the consistency of elevation data when compared to data from other INSPIRE themes. Hence, both cases are described here separately.
-
5.2.5.1. Self-consistency of elevation data
+
5.2.4.1. Self-consistency of elevation data
Elevation data in the different spatial representation types described in this specification should maintain integrity and positional consistency, at least when coming from the same data provider. However, given the current context of elevation data across Europe, it is not possible to establish achievable consistency rules rather than those described in Section 10.
-
5.2.5.2. Consistency of elevation data with other themes
+
5.2.4.2. Consistency of elevation data with other themes
Elevation data is widely used as input data when performing spatial analyses or displaying data from other themes (e.g. hydrography, transport networks, orthoimagery, cadastral parcels, sea regions, etc.) for a wide variety of applications and purposes.
@@ -2366,7 +2344,7 @@
5.2.5.2. Consistency o
-
5.2.6. Identifier management
+
5.2.5. Identifier management
@@ -2404,7 +2382,7 @@
5.2.6. Identifier management
-
5.2.7. Geometry representation
+
5.2.6. Geometry representation
@@ -2439,7 +2417,7 @@
5.2.7. Geometry representation
-
5.2.8. Temporality representation
+
5.2.7. Temporality representation
The application schema(s) use(s) the derived attributes "beginLifespanVersion" and "endLifespanVersion" to record the lifespan of a spatial object.
@@ -2522,7 +2500,7 @@
5.2.8. Temporality representation
-
5.2.9. Coverages
+
5.2.8. 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. isolines), grids (e.g. orthoimages, elevation models), etc.
@@ -2738,7 +2716,7 @@
5.3.1.1.5. Spatial representation types
-
The model incorporated in this specification devotes one application schema for each of these spatial representation types, and an additional one where common enumerations and data types are defined.
+
The model incorporated in this specification devotes one application schema for each of these spatial representation types, and an additional one where common data types are defined.
@@ -2845,7 +2823,7 @@
5.3.1.1.8. Package structure
ElevationBaseTypes
-
This application schema defines basic enumerations and data types which are re-used in the rest of application schemas.
+
This application schema defines basic data types which are re-used in the rest of application schemas.
@@ -2881,7 +2859,7 @@
5.3.1.1.8. Package structure
Each TIN structure is defined according the type GM_Tin type defined in ISO 19107. It consists on a collection of vector spatial objects, such as control points (points having known elevation property values), break lines and stop lines. In addition, this collection stores the necessary parameters which allow the calculation of a triangulation (triangulated surface) in a subsequent process (e.g. a Delaunay triangulation).
-
ElevationGridCoverage, ElevationVectorElements and ElevationTIN application schemas have dependency relationships to the ElevationBaseTypes application schema, since they use generic enumerations defined in it.
+
ElevationGridCoverage, ElevationVectorElements and ElevationTIN application schemas have dependency relationships to the ElevationBaseTypes application schema, since they use generic codelists defined in it.
@@ -2920,37 +2898,27 @@
5.4.1.1. Narrative description
Figure 13 – UML class diagram: Overview of the ElevationBaseTypes application schema
-
The ElevationBaseTypes application schema provides the basic framework for the Elevation theme. Regardless of the spatial representation type used for the elevation data, it defines enumerations which are common to the other Elevation application schemas: ElevationGridCoverage, ElevationVectorElements and ElevationTIN.
+
The ElevationBaseTypes application schema provides the basic framework for the Elevation theme. Regardless of the spatial representation type used for the elevation data, it defines codelist which are common to the other Elevation application schemas: ElevationGridCoverage, ElevationVectorElements and ElevationTIN.
-
5.4.1.1.1. ElevationPropertyTypeValue enumeration
+
5.4.1.1.1. ElevationPropertyTypeValue codelist
As stated in this specification, an elevation property is a vertically-constrained dimensional property of a spatial object consisting of an absolute measure referenced to a well-defined surface which is commonly taken as origin (e.g. a geoid, a specific water level, etc.).
-
This enumeration establishes the possible types of elevation properties with regard to the orientation of the measurement with respect to the Earth’s gravity field direction:
-
-
-
-
-
height (measured in a direction opposite to Earth’s gravity field - upwards direction), and;
-
-
-
depth (measured in the same direction of Earth’s gravity field - downwards direction).
-
-
+
This codelist establishes the possible types of elevation properties with regard to the orientation of the measurement with respect to the Earth’s gravity field direction.
-
This enumeration is defined in Section 5.4.2.1.1.
+
This codelist is defined in Section 5.4.2.1.1.
-
5.4.1.1.2. SurfaceTypeValue enumeration
+
5.4.1.1.2. SurfaceTypeValue codelist
-
This enumeration establishes the different types of DEMs taking into account the relative adherence of the surface modelled to the Earth’s bare surface. The possible values are DTM and DSM.
+
This codelist establishes the different types of DEMs taking into account the relative adherence of the surface modelled to the Earth’s bare surface.
-
This enumeration is defined in Section 5.4.2.1.2.
+
This codelist is defined in Section 5.4.2.1.2.
@@ -2994,18 +2962,17 @@
5.4.2. Feature catalogue
-
5.4.2.1. Enumerations
+
5.4.2.1. Code lists
5.4.2.1.1. ElevationPropertyTypeValue
-
+
-
-
+
+
-
ElevationPropertyTypeValue
-
+
ElevationPropertyTypeValue
@@ -3015,7 +2982,7 @@
5.4.2.1.1. ElevationPropertyTypeValue
Definition:
-
Enumeration type which determines the elevation property which has been measured or calculated.
+
Code list type which determines the elevation property which has been measured or calculated.
Description:
@@ -3026,47 +2993,30 @@
5.4.2.1.1. ElevationPropertyTypeValue
EXAMPLE Height, depth.
-
URI:
-
-
-
-
Value:
-
height
-
-
-
Definition:
-
Elevation property measured along a plumb line in a direction opposite to Earth’s gravity field (upwards).
+
Extensibility:
+
none
-
Description:
-
NOTE This definition intentionally avoids making reference to complex geodetic terms. It is only intended to specify the direction in which the elevation property has been measured.
Elevation property measured along a plumb line in a direction coincident to Earth’s gravity field (downwards).
-
-
-
Description:
-
NOTE This definition intentionally avoids making reference to complex geodetic terms. It is only intended to specify the direction in which the elevation property has been measured.
+
The allowed values for this code list comprise only the values specified in the INSPIRE Registry.
5.4.2.1.2. SurfaceTypeValue
-
+
-
-
+
+
-
SurfaceTypeValue
-
+
SurfaceTypeValue
@@ -3076,49 +3026,23 @@
5.4.2.1.2. SurfaceTypeValue
Definition:
-
Enumeration type which determines the elevation surface with regard to its relative adherence to the Earth’s bare surface.
+
Code list type which determines the elevation surface with regard to its relative adherence to the Earth’s bare surface.
Description:
EXAMPLE DTM and DSM.
-
URI:
-
-
-
-
Value:
-
DTM
-
-
-
Definition:
-
Digital terrain model.
+
Extensibility:
+
none
-
Description:
-
EXAMPLE Buildings, bridges or vegetation do not form part of a DTM.
-
-NOTE 1 For DTM surfaces describing the floor of water bodies (e.g. the sea-floor), the water bodies are not considered as part of the Earth’s bare surface. Hence, they are excluded from the DTM.
-
-NOTE 2 For DTM surfaces in which any features placed on the Earth’s bare surface have not been totally filtered and excluded, the deviations must be explained in the metadata.
EXAMPLE 1 Vegetation, buildings and bridges are examples of static features.
-
-EXAMPLE 2 Cars, trucks and other dynamic features are examples of temporary phenomena.
-
-NOTE 1 For DSM surfaces describing the floor of water bodies (e.g. the sea-floor) and those features placed on it, the water bodies are not considered as part of the Earth’s bare surface. Hence, they are excluded from the DSM.
-
-NOTE 2 For DSM surfaces in which any temporary phenomena have not been totally filtered and excluded, the deviations must be explained in the metadata.
+
The allowed values for this code list comprise only the values specified in the INSPIRE Registry.
@@ -3802,10 +3726,10 @@
5.5.2. Feature catalogue
5.5.2.1. Spatial object types
5.5.2.1.1. ElevationGridCoverage
-
+
-
-
+
+
@@ -4064,10 +3988,10 @@
5.5.2.1.1. ElevationGridCoverage
5.5.2.2. Data types
5.5.2.2.1. ElevationGridCoverageAggregation
-
+
-
-
+
+
@@ -4139,14 +4063,14 @@
5.5.2.2.2. ElevationGridCoverageAgg
5.5.2.3. 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.
+
This section lists definitions for feature types, data types and code lists that are defined in other application schemas. The section is purely informative and should help the reader understand the feature catalogue presented in the previous sections. For the normative documentation of these types, see the given references.
5.5.2.3.1. DateTime
-
+
-
-
+
+
@@ -4193,10 +4117,10 @@
5.5.2.3.2. EX_Extent
5.5.2.3.3. ElevationPropertyTypeValue
-
+
-
-
+
+
@@ -4214,7 +4138,7 @@
5.5.2.3.3. ElevationPropertyTypeValue
Definition:
-
Enumeration type which determines the elevation property which has been measured or calculated.
+
Code list type which determines the elevation property which has been measured or calculated.
Description:
@@ -4229,10 +4153,10 @@
5.5.2.3.3. ElevationPropertyTypeValue
5.5.2.3.4. GM_MultiSurface
-
+
-
-
+
+
@@ -4253,10 +4177,10 @@
5.5.2.3.4. GM_MultiSurface
5.5.2.3.5. Identifier
-
+
-
-
+
+
@@ -4289,10 +4213,10 @@
5.5.2.3.5. Identifier
5.5.2.3.6. RectifiedGridCoverage
-
+
-
-
+
+
@@ -4323,10 +4247,10 @@
5.5.2.3.6. RectifiedGridCoverage
5.5.2.3.7. SurfaceTypeValue
-
+
-
-
+
+
@@ -4344,7 +4268,7 @@
5.5.2.3.7. SurfaceTypeValue
Definition:
-
Enumeration type which determines the elevation surface with regard to its relative adherence to the Earth’s bare surface.
+
Code list type which determines the elevation surface with regard to its relative adherence to the Earth’s bare surface.
+
INSPIRE Infrastructure for Spatial Information in Europe
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+