INSPIRE
Infrastructure for Spatial Information in Europe
D2.8.III.10 Data Specification on Population Distribution -
Demography – Draft Guidelines
Title D2.8.III.10 INSPIRE Data Specification on Population Distribution - Demography –
Draft Guidelines
Creator INSPIRE Thematic Working Group Population Distribution - Demography
Date 2012-07-09
Subject INSPIRE Data Specification for the spatial data theme Population Distribution -
Demography
Publisher INSPIRE Thematic Working Group Population Distribution - Demography
Description This document describes the INSPIRE Data Specification for the spatial data theme
Population Distribution - Demography
Contributor Members of the INSPIRE Thematic Working Group Population Distribution -
Demography
Rights Public
Identifier D2.8.III.10_v3
Relation Directive 2007/2/EC of the European Parliament and of the Council of 14 March 2007
establishing an Infrastructure for Spatial Information in the European Community (INSPIRE)
Foreword
How to read the document?
This document describes the “INSPIRE data specification on Population Distribution - Demography – Guidelines” version 2.9 as developed by the Thematic Working Group (TWG) SU-PD using both natural and a conceptual schema language.
The data specification is based on a common template used for all data specifications and has been harmonised using the experience from the development of the Annex I data specifications.
This document provides guidelines for the implementation of the provisions laid down in the draft Implementing Rule for spatial data sets and services of the INSPIRE Directive.
This document includes two executive summaries that provide a quick overview of the INSPIRE data specification process in general, and the content of the data specification on Population Distribution - Demography in particular. We highly recommend that managers, decision makers, and all those new to the INSPIRE process and/or information modelling should read these executive summaries first.
The UML diagrams (in Chapter 5) offer a rapid way to see the main elements of the specifications and their relationships. The definition of the spatial object types, attributes, and relationships are included in the Feature Catalogue (also in Chapter 5). People having thematic expertise but not familiar with UML can fully understand the content of the data model focusing on the Feature Catalogue. Users might also find the Feature Catalogue especially useful to check if it contains the data necessary for the applications that they run. The technical details are expected to be of prime interest to those organisations that are/will be responsible for implementing INSPIRE within the field of Population Distribution - Demography.
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 will be based on the infrastructures for spatial information that are created and maintained by the Member States. To support the establishment of a European infrastructure, Implementing Rules addressing the following components of the infrastructure are being specified: metadata, interoperability of spatial data themes (as described in Annexes I, II, III of the Directive) and spatial data services, network services and technologies, data and service sharing, and monitoring and reporting procedures.
INSPIRE does not require collection of new data. However, after the period specified in the Directive1 Member States have to make their data available according to the Implementing Rules.
Interoperability in INSPIRE means the possibility to combine spatial data and services from different sources across the European Community in a consistent way without involving specific efforts of humans or machines. It is important to note that “interoperability” is understood as providing access to spatial data sets through network services, typically via Internet. Interoperability may be achieved by either changing (harmonising) and storing existing data sets or transforming them via services for publication in the INSPIRE infrastructure. It is expected that users will spend less time and efforts on understanding and integrating data when they build their applications based on data delivered within INSPIRE.
In order to benefit from the endeavours of international standardisation bodies and organisations established under international law their standards and technical means have been utilised and referenced, whenever possible.
To facilitate the implementation of INSPIRE, it is important that all stakeholders have the opportunity to participate in specification and development. For this reason, the Commission has put in place a consensus building process involving data users, and providers together with representatives of industry, research and government. These stakeholders, organised through Spatial Data Interest Communities (SDIC) and Legally Mandated Organisations (LMO)2, have provided reference materials, participated in the user requirement and technical3 surveys, proposed experts for the Data Specification Drafting Team4 and Thematic Working Groups5 and participated in the public
1 For all 34 Annex I,II and III data themes: within two years of the adoption of the corresponding
Implementing Rules for newly collected and extensively restructured data and within 5 years for other data in electronic format still in use
2 The current status of registered SDICs/LMOs is available via INSPIRE website:
http://inspire.jrc.ec.europa.eu/index.cfm/pageid/42
3 Surveys on unique identifiers and usage of the elements of the spatial and temporal schema, 4
The Data Specification Drafting Team has been composed of experts from Austria, Belgium, Czech Republic, France, Germany, Greece, Italy, Netherlands, Norway, Poland, Switzerland, UK, and the European Environment Agency
5 The Thematic Working Groups of Annex II and III themes have been composed of experts from
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 specifications6.
This open and participatory approach was successfully used during the development of the data specification on Annex I data themes as well as during the preparation of the Implementing Rule on Interoperability of Spatial Data Sets and Services7 for Annex I spatial data themes.,
The development framework elaborated by the Data Specification Drafting Team aims at keeping the data specifications of the different themes coherent. It summarises the methodology to be used for the data specifications and provides a coherent set of requirements and recommendations to achieve interoperability. The pillars of the framework are five technical documents:
• The Definition of Annex Themes and Scope8 describes in greater detail the spatial data
themes defined in the Directive, and thus provides a sound starting point for the thematic aspects of the data specification development.
• The Generic Conceptual Model9 defines the elements necessary for interoperability and
data harmonisation including cross-theme issues. It specifies requirements and recommendations with regard to data specification elements of common use, like the spatial and temporal schema, unique identifier management, object referencing, a generic network model, some common code lists, etc. Those requirements of the Generic Conceptual Model that are directly implementable will be included in the Implementing Rule on Interoperability of Spatial Data Sets and Services.
• The Methodology for the Development of Data Specifications10 defines a repeatable
methodology. It describes how to arrive from user requirements to a data specification through a number of steps including use-case development, initial specification development and analysis of analogies and gaps for further specification refinement.
• The “Guidelines for the Encoding of Spatial Data”11 defines how geographic information
can be encoded to enable transfer processes between the systems of the data providers in the Member States. Even though it does not specify a mandatory encoding rule it sets GML (ISO 19136) as the default encoding for INSPIRE.
• The “Guidelines for the use of Observations & Measurements and Sensor Web
Enablement-related standards in INSPIRE Annex II and III data specification development” provides guidelines on how the “Observations and Measurements” standard (ISO 19156) is to be used within INSPIRE.
The structure of the data specifications is based on the “ISO 19131 Geographic information - Data product specifications” standard. They include the technical documentation of the application schema, the spatial object types with their properties, and other specifics of the spatial data themes using natural language as well as a formal conceptual schema language12.
Italy, Latvia, Netherlands, Norway, Poland, Romania, Slovakia, Spain, Sweden, Switzerland, Turkey, UK, the European Commission, and the European Environment Agency
6
For Annex II+III, the consultation phase lasted from 20 June to 21 October 2011.
7
Commission Regulation (EU) No 1089/2010 implementing Directive 2007/2/EC of the European Parliament and of the Council as regards interoperability of spatial data sets and services, published in the Official Journal of the European Union on 8th of December 2010.
8http://inspire.jrc.ec.europa.eu/reports/ImplementingRules/DataSpecifications/D2.3_Definition_of_Ann ex_Themes_and_scope_v3.0.pdf 9 http://inspire.jrc.ec.europa.eu/reports/ImplementingRules/DataSpecifications/D2.5_v3.3.pdf 10 http://inspire.jrc.ec.europa.eu/reports/ImplementingRules/DataSpecifications/D2.6_v3.0.pdf 11http://inspire.jrc.ec.europa.eu/reports/ImplementingRules/DataSpecifications/D2.7_v3.2.pdf 12
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 schemas13 developed for each spatial data theme. The multilingual INSPIRE Feature Concept Dictionary contains the definition and description of the INSPIRE themes together with the definition of the spatial object types present in the specification. The INSPIRE Glossary defines all the terms (beyond the spatial object types) necessary for understanding the INSPIRE documentation including the terminology of other components (metadata, network services, data sharing, and monitoring).
By listing a number of requirements and making the necessary recommendations, the data specifications enable full system interoperability across the Member States, within the scope of the application areas targeted by the Directive. Once finalised (version 3.0), the data specifications are published as technical guidelines and provide the basis for the content of the Implementing Rule on Interoperability of Spatial Data Sets and Services14. The content of the Implementing Rule is extracted from the data specifications keeping in mind short- and medium-term feasibility as well as cost-benefit considerations. The requirements included in the Implementing Rule will be legally binding for the Member States according to the timeline specified in the INSPIRE Directive.
In addition to providing a basis for the interoperability of spatial data in INSPIRE, the data specification development framework and the thematic data specifications can be reused in other environments at local, regional, national and global level contributing to improvements in the coherence and interoperability of data in spatial data infrastructures.
13 Conceptual models related to specific areas (e.g. INSPIRE themes)
14 In the case of the Annex II+III data specifications, the extracted requirements will be used to
Population Distribution - Demography – Executive
Summary
Population distributions are defined as “datasets of statistical information describing how some phenomenon regarding human population is spread within some part of the 2D space”. This document presents data specifications for population distributions. It is based on the following principles:
Separation between statistical data and statistical units
A statistical data is defined as “any numerical representation of a phenomenon”. A statistical unit informs on the statistical data location. This document addresses only the statistical data specification: The specification of statistical unit is out of the scope of this document. Statistical data refers to statistical units through their common identifier, e.g. NUTS codes. Linking statistical data to spatial object is not only linking a database object to another one. The challenge is to improve the interaction between the statistics and the GIS worlds. This document recommendations aims at improving the integration of spatial and statistic analyses. The result of the integration makes the treasure of statistical data available for the GIS world in context of a spatial data infrastructure of the administration.
Genericity
There are many different kinds of statistical data about human population: about people, dwellings, people at their work place, etc. This document does not intend to provide specifications for all these. Common characteristics have been extracted and represented into a generic data model. Using the data model described in this specification, all statistical data regularly organized in tables or data cubes can be provided in the INSPIRE framework.
Acknowledgements
Many individuals and organisations have contributed to the development of these Guidelines.
The Thematic Working Group on Statistical Units and Population Distribution (TWG-SU-PD) included: Alina Kmiecik (TWG Facilitator until 15/12/2010) and Udo Maack (TWG Facilitator from 15/12/2010, TWG co-editor from 09/2011), Pieter Bresters, Ian Coady, Marie Haldorson, Jean-Luc Lipatz (TWG Editor until 09/2011), Miroslaw Migacz, Susanne Schnorr-Baecker, Julien Gaffuri (European Commission contact point, TWG co-editor from 09/2011).
Contributors:
From Eurostat: Beatrice Eiselt, Ekkehard Petri and Daniele Rizzi From CBS (NL): Niek van Leeuwen, Olav ten Bosch
Participants on GISCO / Geostat meetings:
Hugo Poelmann (DG Regio) – Requirements for Change Information Ingrid Kaminger (Statistic Austria) – User Survey according Grids
Marjan van Herwijnen (ESPON-Coordination Unit) - Requirements for Change Information
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) or Legally Mandated Organisations (LMOs).
Contact information
Vanda Nunes de Lima
European Commission Joint Research Centre Institute for Environment and Sustainability Spatial Data Infrastructures Unit
TP262, Via Fermi 2749 I-21027 Ispra (VA) ITALY E-mail: [email protected] Tel.: +39-0332-7865052 Fax: +39-0332-7866325 http://ies.jrc.ec.europa.eu/ http://ec.europa.eu/dgs/jrc/ http://inspire.jrc.ec.europa.eu/
Table of contents
1 Scope ...Error! Bookmark not defined.
2 Overview ... 1
2.1 Name... 1
2.2 Informal description... 1
2.3 Normative References ... 2
2.4 Terms and definitions... 3
2.5 Symbols and abbreviations ... 4
2.6 Notation of requirements and recommendations... 4
2.7 Conformance... 4
3 Specification scopes ... 5
4 Identification information...Error! Bookmark not defined. 5 Data content and structure ... 6
5.1 Basic notions...Error! Bookmark not defined. 5.1.1 Stereotypes...Error! Bookmark not defined. 5.1.2 Placeholder and candidate types...Error! Bookmark not defined. 5.1.3 Voidable characteristics...Error! Bookmark not defined. 5.1.4 Enumerations...Error! Bookmark not defined. 5.1.5 Code lists ...Error! Bookmark not defined. 5.2 Application schema Population Distribution – Demography ... 11
5.2.1 Description ... 11
5.2.2 Feature catalogue ...Error! Bookmark not defined. 5.2.3 INSPIRE-governed code lists ... 35
5.2.4 Externally governed code lists ... 38
6 Reference systems ...Error! Bookmark not defined. 6.1 Datum...Error! Bookmark not defined. 6.2 ...Error! Bookmark not defined. 6.3 For the coordinate reference systems used for making available the INSPIRE spatial data sets, the datum shall be the datum of the European Terrestrial Reference System 1989 (ETRS89) in areas within its geographical scope, and the datum of the International Terrestrial Reference System (ITRS) or other geodetic coordinate reference systems compliant with ITRS in areas that are outside the geographical scope of ETRS89. Compliant with the ITRS means that the system definition is based on the definition of the ITRS and there is a well-established and described relationship between both systems, according to EN ISO 19111. ...Error! Bookmark not defined. 6.3.1 Two-dimensional Coordinate Reference Systems ...Error! Bookmark not defined. 6.4 For the vertical component on land, the European Vertical Reference System (EVRS) shall be used to express gravity-related heights within its geographical scope...Error! Bookmark not defined. 6.5 Temporal reference system ...Error! Bookmark not defined. 6.6 Theme-specific requirements and recommendations on reference systems ... 41
7 Data quality... 42
7.1 Data quality elements... 42
7.2 Minimum data quality requirements ... 42
7.3 Recommendation on data quality ... 42
8 Dataset-level metadata ... 43
8.1 Common metadata elements...Error! Bookmark not defined.
8.1.1 Coordinate Reference System...Error! Bookmark not defined.
8.1.3 Encoding ...Error! Bookmark not defined.
8.1.4 Character Encoding ...Error! Bookmark not defined.
8.1.5 Data Quality – Logical Consistency – Topological ConsistencyError! Bookmark not defined.
8.2 Metadata elements for reporting data quality ...Error! Bookmark not defined.
8.3 Theme-specific metadata elements ... 50
8.3.1 <Name of Metadata Element>... 51
8.3.2 Maintenance Information ...Error! Bookmark not defined. 8.4 Guidelines on using metadata elements defined in Regulation 1205/2008/EC ...Error! Bookmark not defined. 8.4.1 Conformity...Error! Bookmark not defined. 8.4.2 Lineage ...Error! Bookmark not defined. 8.4.3 Temporal reference ...Error! Bookmark not defined. 8.4.4 <MD Element from MD Regulation>... 53
9 Delivery ... 54
9.1 Delivery medium ...Error! Bookmark not defined. 9.2 Encodings ... 54 9.2.1 Default Encoding(s) ... 54 9.2.2 Alternative Encoding(s)... 55 10 Data Capture... 56 11 Portrayal ... 57 Bibliography... 60
Annex B (normative) Abstract Test Suite ...Error! Bookmark not defined. Annex A (informative) Use cases ... 62
1 Scope
This document specifies a harmonised data specification for the spatial data theme Population Distribution - Demography as defined in Annex III of the INSPIRE Directive.
This data specification provides the basis for the drafting of Implementing Rules according to Article 7 (1) of the INSPIRE Directive [Directive 2007/2/EC]. The entire data specification will be published as implementation guidelines accompanying these Implementing Rules.
2 Overview
2.1 Name
INSPIRE data specification for the theme Population Distribution - Demography.
2.2 Informal description
Definition:
Geographical distribution of people, including population characteristics and activity levels, aggregated by grid, region, administrative unit or other analytical unit [Directive 2007/2/EC].
Description:
Population = human population
A population is any entire collection of people, animals, plants or things about which we may collect data. It is the entire group we are interested in, which we wish to describe or draw conclusions about. In this data specification population is referring to human beings, i.e. (1) people such as individuals or (2) people living together in households for instance. Information on people where and how they live or stay are crucial for nearly all other themes of the INSPIRE Directive, in particular to Human Health and Safety, Buildings and Natural Risk Zones.
The theme may thematically be divided into several components. The directive text points at broad groups of sub-themes:
• Human population by individual characteristics (sex, age, marital status, nationality). • Human population activity levels (education, profession)
• Human beings living together in groups for different reasons (households, institutions such as
retirement homes)
Wide ranges of statistics on population are available
Concerning population information, this may include total population, age, gender, nationality or place of birth in terms of stocks, or mortality, life expectancy and migration in terms of flows. Of interest could be the population with reference to a time period and activities. Use cases point to the need for a distinction between night time and daytime population for a given regional unit such as a city or a sub-city. It might be difficult to determine how many people are in a specific place (settlement, apartment or house) and to which groups they belong. According to people’s activities, they can be at work or enjoy leisure time activities (such as watching a movie in the cinema) or they can spend their time in transport facilities. For people at work, it can be shown to which economic sector in terms of NACE they belong in a specific place, region or part of it or where people of a given socio
demographic group live for instance in towns or at the border. All such information could be useful in the context of other thematic themes such as agriculture or the usage of natural resources.
To minimize the overlap with additional powerful harmonized European sources like Eurostat’s Regional database, only a few population distribution data are mandatory. It is recommended that Eurostat provide additional statistical data by INSPIRE services.
No spatial features
The theme Population distribution/demography contains attributes related to statistical units. This means that this theme has no direct spatial features such as many other INSPIRE Annex III themes like buildings, health care institutions etc., it needs to be linked to these features by the use of statistical units for example NUTS-codes or grid identifier.
Aggregated data and confidentiality issues
The definition in the Directive 2007/2/EC specifies all kinds of features relevant to demography. It includes the term "aggregated" which means that non-aggregated data about population is excluded because of confidentiality. The data provision on different regional levels depends on the national situation regarding availability and privacy. There is a correlation between size of statistical units and differentiation of the attribute values. The smaller the size of the statistical units, the more undifferentiated the attributes can be to meet the data privacy rules. The data model covers all the possibilities but legal restrictions may prohibit the provision.
Population distribution/Demography in the INSPIRE context
Population distribution/Demography is a very wide phenomenon that may be described by quantitative data from different sources - both on national and European level. This data specification provides a generic data model which covers various statistical domains. Use-cases show that statistics on total population on grids or other small areas could be widely used together with other INSPIRES themes. Due to the complexity and large amount of statistics describing population, the requirement 3 stated in 5.2 is to provide total population and population by age groups on municipalities and 1km2 grid level.
The benefits from this theme in the context of INSPIRE should primarily be the access to existing statistics which are not already published in regional databases provided by Eurostat or the member states. The statistics provided according to this INSPIRE theme should rather be a complement to statistics already being published based on legislation and gentlemen’s agreements. Statistics in national or European regional databases are often multidimensional in a way that the INSPIRE services could never match, and existing databases should therefore be considered as the best source of information on demography.
The genericity of the model is expressed in using different code lists for classification of each statistical value provided. This approach includes the flexibility to react to further requirements coming from new legislations or other reasons.
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)
REGULATION (EC) No 177/2008 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 20 February 2008 establishing a common framework for business registers for statistical purposes and repealing Council Regulation (EEC) No 2186/93
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
REGULATION (EC) No 763/2008 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 9 July 2008 on population and housing censuses
COMMISSION REGULATION (EC) No 1201/2009 of 30 November 2009 implementing Regulation (EC) No 763/2008 as regards the technical specifications of the topics and of their breakdowns
COMMISSION REGULATION (EU) No 519/2010 of 16 June 2010 adopting the programme of the statistical data and of the metadata for population and housing censuses provided for by Regulation (EC) No 763/2008
REGULATION (EU) No 1151/2010 of 08 December 2010 implementing Regulation (EC) No 763/2008, as regards the modalities and structure of the quality reports and the technical format for data transmission
REGULATION (EC) No 1177/2003 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 16 June 2003concerning Community statistics on income and living conditions (EU-SILC)
REGULATION (EC) No 295/2008 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 11 March 2008 concerning structural business statistics
COUNCIL REGULATION (EC) No 577/98 of 9 March 1998 COUNCIL REGULATION (EC) No 577/98 of 9 March 1998 on the organisation of a labour force sample survey in the Community
REGULATION (EC) No. 1059/2003 on the establishment of a common classification of territorial units for statistics (NUTS2003)
REGULATION (EC) No. 105/2007 Amending the Annexes to Regulation 1059/2007 (NUTS2006) REGULATION (EC) No. 31/2011 Amending the Annexes to Regulation 1059/2007 (NUTS2010)
REGULATION (EC) No 862/2007 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 11 July 2007 on Community statistics on migration and international protection and repealing Council Regulation (EEC) No 311/76 on the compilation of statistics on foreign workers
[ISO 19107] EN ISO 19107:2005, Geographic Information – Spatial Schema
[ISO 19108-c] ISO 19108:2002/Cor 1:2006, Geographic Information – Temporal Schema, Technical Corrigendum 1
[ISO 19113] EN ISO 19113:2005, Geographic Information – Quality principles
[ISO 19115] EN ISO 19115:2005, Geographic information – Metadata (ISO 19115:2003)
[ISO 19138] ISO/TS 19138:2006, Geographic Information – Data quality measures
[Regulation 1205/2008/EC] Regulation 1205/2008/EC implementing Directive 2007/2/EC of the European Parliament and of the Council as regards metadata
General terms and definitions helpful for understanding the INSPIRE data specification documents are defined in the INSPIRE Glossary15.
2.5 Symbols and abbreviations
Eurostat Statistical Office of the European CommunitiesNACE Statistical classification of economic activities in the European Community NUTS Nomenclature of Territorial Units for Statistics
UML Unified Modelling Language
2.6 Notation of requirements and recommendations
To make it easier to identify the mandatory requirements and the recommendations for spatial data sets in the text, they are highlighted and numbered.
IR Requirement X Requirements that are reflected in the Implementing Rule on interoperability of
spatial data sets and services are shown using this style.
DS Requirement X Requirements that are not reflected in the Implementing Rule on
interoperability of spatial data sets and services are shown using this style.
Recommendation 1 Recommendations are shown using this style.
2.7 Conformance
DS Requirement 1 Any dataset claiming conformance with this INSPIRE data specification shall pass the requirements described in the abstract test suite presented in Annex A.
Error! Not a valid filename.
15 The INSPIRE Glossary is available from
3 Specification scopes
This data specification does not distinguish different specification scopes, but just considers one general scope.
NOTE For more information on specification scopes, see [ISO 19131:2007], clause 8 and Annex D.
4 Identification information
NOTE Since the content of this chapter was redundant with the overview description (section 2) and executive summary, it has been decided that this chapter will be removed in v3.0.
5 Data content and structure
5.1 Basic notions
This section explains some of the basic notions used in the INSPIRE application schemas. These explanations are based on the GCM [DS-D2.5].
5.1.1
Stereotypes
In the application schemas in this sections several stereotypes are used that have been defined as part of a UML profile for use in INSPIRE [DS-D2.5]. These are explained in Table 1 below.
Table 1 – Stereotypes (adapted from [DS-D2.5])
Stereotype Model
element Description
applicationSchema Package An INSPIRE application schema according to ISO 19109 and the Generic Conceptual Model.
leaf Package A package that is not an application schema and contains no packages.
featureType Class A spatial object type.
placeholder Class A class that acts as a placeholder for a class, typically a spatial object type, that will be specified in the future as part of another spatial data theme. The class should at least have a definition, but may otherwise have a preliminary or no specification (see section 5.1.2).
type Class A conceptual, abstract type that is not a spatial object type. dataType Class A structured data type without identity.
union Class A structured data type without identity where exactly one of the properties of the type is present in any instance.
enumeration Class A fixed list of valid identifiers of named literal values. Attributes of an enumerated type may only take values from this list.
codeList Class A code list.
import Dependency The model elements of the supplier package are imported. voidable Attribute,
association role
A voidable attribute or association role (see section 5.1.3).
lifeCycleInfo Attribute, association role
If in an application schema a property is considered to be part of the life-cycle information of a spatial object type, the property shall receive this stereotype.
version Association
role
If in an application schema an association role ends at a spatial object type, this stereotype denotes that the value of the property is meant to be a specific version of the spatial object, not the spatial object in general.
5.1.2
Placeholder and candidate types
Some of the INSPIRE Annex I data specifications (which were developed previously to the Annex II+III data specifications) refer to types that were considered to thematically belong and which were
expected to be fully specified in Annex II or III spatial data themes. Two kinds of such types were distinguished:
− Placeholder types were created as placeholders for types (typically spatial object types) that
were to be specified as part of a future spatial data theme, but which was already used as a value type of an attribute or association role in this data specification.
Placeholder types received the stereotype «placeholder» and were placed in the application schema package of the future spatial data theme where they thematically belong. For each placeholder, a definition was specified based on the requirements of the Annex I theme. The Annex II+III TWGs were required to take into account these definitions in the specification work of the Annex II or III theme.
If necessary, the attributes or association roles in the Annex I data specification(s) that have a placeholder as a value type shall be updated.
− Candidate types were types (typically spatial object types) for which already a preliminary
specification was given in the Annex I data specification. Candidate types did not receive a specific stereotype and were placed in the application schema package of the future spatial data theme where they thematically belong. For each candidate type, a definition and attributes and association roles were specified based on the requirements of the Annex I theme. The Annex II+III TWGs were required to take into account these specifications in the specification work of the Annex II or III theme.
If the type could not be incorporated in the Annex II or III data specification according to its preliminary specification, it should be moved into the application schema of the Annex I theme where it had first been specified. In this case, the attributes or association roles in the Annex I data specification(s) that have the type as a value type shall be updated if necessary.
NOTE Once the Annex II+III data specifications have been finalised by the TWGs (version 3.0), all placeholders and candidate types should have been removed. In some cases, this may require one or several of the Annex I data specifications (and the Implementing Rule on interoperability of spatial data sets and services) to be updated.
5.1.3
Voidable characteristics
If a characteristic of a spatial object is not present in the spatial data set, but may be present or applicable in the real world, the property shall receive this stereotype.
If and only if a property receives this stereotype, the value of void may be used as a value of the property. A void value shall imply that no corresponding value is contained in the spatial data set maintained by the data provider or no corresponding value can be derived from existing values at reasonable costs, even though the characteristic may be present or applicable in the real world.
It is possible to qualify a value of void in the data with a reason using the VoidValueReason type. The VoidValueReason type is a code list, which includes the following pre-defined values:
− Unpopulated: The characteristic is not part of the dataset maintained by the data provider.
However, the characteristic may exist in the real world. For example when the “elevation of the water body above the sea level” has not been included in a dataset containing lake spatial objects, then the reason for a void value of this property would be ‘Unpopulated’. The characteristic receives this value for all objects in the spatial data set.
− Unknown: The correct value for the specific spatial object is not known to, and not computable
by the data provider. However, a correct value may exist. For example when the “elevation of the water body above the sea level” of a certain lake has not been measured, then the reason for a void value of this property would be ‘Unknown’. This value is applied on an object-by-object basis in a spatial data set.
NOTE It is expected that additional reasons will be identified in the future, in particular to support reasons / special values in coverage ranges.
The «voidable» stereotype does not give any information on whether or not a characteristic exists in the real world. This is expressed using the multiplicity:
− If a characteristic may or may not exist in the real world, its minimum cardinality shall be defined
as 0. For example, if an Address may or may not have a house number, the multiplicity of the corresponding property shall be 0..1.
− If at least one value for a certain characteristic exists in the real world, the minimum cardinality
shall be defined as 1. For example, if an Administrative Unit always has at least one name, the multiplicity of the corresponding property shall be 1..*.
In both cases, the «voidable» stereotype can be applied. A value (the real value or void) only needs to be made available for properties that have a minimum cardinality of 1.
5.1.4
Enumerations
Enumerations are modelled as classes in the application schemas. Their values are modelled as attributes of the enumeration class using the following modelling style:
− No initial value, but only the attribute name part, is used.
− The attribute name conforms to the rules for attributes names, i.e. is a lowerCamelCase name.
Exceptions are words that consist of all uppercase letters (acronyms).
IR Requirement 1 Attributes of spatial object types or data types whose type is an enumeration
shall only take values included in the enumeration.
5.1.5
Code lists
Code lists are modelled as classes in the application schemas. Their values, however, are managed outside of the application schema.
5.1.5.1. Obligation
For each attribute that has a code list as its value, a tagged value called “obligation” is specified to define the level of obligation to use values from the list. The tagged value can take the following values:
− IR means that only the values defined by the code list shall be used for the attribute. This
obligation is also included in the Implementing Rule on interoperability of spatial data and services.
− TG means that only the values defined by the code list should be used for the attribute. This
obligation is not included in the Implementing Rule on interoperability of spatial data and services.
IR Requirement 2 Attributes of spatial object types or data types whose type is a code list with an “obligation” value of “IR” shall only take values that are valid according to the code list’s specification.
Recommendation 1 Attributes of spatial object types or data types whose type is a code list with an “obligation” value of “TG” should only take values that are valid according to the code list’s specification.
5.1.5.2. Governance
− Code lists that are governed by INSPIRE (INSPIRE-governed code lists). These code lists will
be managed centrally in the INSPIRE code list register, which is managed and governed by the INSPIRE expert group on maintenance and implementation. Change requests to these code lists (e.g. to add, deprecate or supersede values) are processed and decided upon using the maintenance workflows defined by the INSPIRE expert group.
INSPIRE-governed code lists will be made available in the INSPIRE code list register at http://inspire.ec.europa.eu/codeList/<CodeListName>. They will be available in SKOS/RDF, XML and HTML. The maintenance will follow the procedures defined in ISO 19135. This means that the only allowed changes to a code list are the addition, deprecation or supersession of values, i.e. no value will ever be deleted, but only receive different statuses (valid, deprecated, superseded). Identifiers for values of INSPIRE-governed code lists are constructed using the pattern http://inspire.ec.europa.eu/codeList/<CodeListName>/<value>.
− Code lists that are governed by an organisation outside of INSPIRE (externally governed code
lists). These code lists are managed by an organisation outside of INSPIRE, e.g. the World Meteorological Organization (WMO) or the World Health Organization (WHO). Change requests to these code lists follow the maintenance workflows defined by the maintaining organisations. Note that in some cases, no such workflows may be formally defined.
−
− The tables describing externally governed code lists in this section contain the following
columns:
The Governance column describes the external organisation that is responsible for maintaining the code list.
If the code list is versioned, the Version column specifies which version of the code list shall be used in INSPIRE. The version can be specified using a version number or the publication date of a version. The specification can also refer to the “latest available version”.
− The Availability column specifies from where the values of the externally governed code
list are available, through a URL for code lists that are available online, or a citation for code lists that are only available offline.
− In the Formats column the formats are listed, in which a code list is available. These can
be machine-readable (e.g. SKOS/RDF, XML) or human-readable (e.g. HTML, PDF).
− In some cases, for INSPIRE only a subset of an externally governed code list is relevant.
The subset is specified using the Subset column.
− For encoding values of externally governed code lists, rules have to be specified for
generating URI identifiers and labels for code list values. These are specified in a separate table.
−
− 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 thevalue 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 beused 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}".
−
− Extensibility −
− For each code list, a tagged value called “extensibility” is specified to define which
additional values (other than those explicitly specified) are allowed as valid values of the code list. The tagged value can take the following values:
nonemeans that only the values explicitly specified shall / should16 be used for the attribute. narrower means that only the values explicitly specified or values narrower than the specified values shall / should be used for the attribute.
anymeans that, in addition to the values explicitly specified, any other value may be used.
5.1.5.3.
NOTE The “extensibility” tagged value does not affect the possibility to update the code list values following the formal maintenance procedure. For example, even for code lists, for which the “extensibility” is set to none, it is still possible to add values following the maintenance procedure of the code list. As a result of this update, the code list may include additional valid values, and these additional may be used for attributes having the code list as a type.
Coverages
Coverage functions are used to describe characteristics of real-world phenomena that vary over space and/or time. Typical examples are temperature, elevation, precipitation, imagery. A coverage contains a set of such values, each associated with one of the elements in a spatial, temporal or spatio-temporal domain. Typical spatial domains are point sets (e.g. sensor locations), curve sets (e.g. contour lines), grids (e.g. orthoimages, elevation models), etc.
In INSPIRE application schemas, coverage functions are defined as properties of spatial object types where the type of the property value is a realisation of one of the types specified in ISO 19123.
To improve alignment with coverage standards on the implementation level (e.g. ISO 19136 and the OGC Web Coverage Service) and to improve the cross-theme harmonisation on the use of coverages in INSPIRE, an application schema for coverage types is included in the Generic Conceptual Model in 9.9.4. This application schema contains the following coverage types:
RectifiedGridCoverage: coverage whose domain consists of a rectified grid – a grid for which there is an affine transformation between the grid coordinates and the coordinates of a coordinate reference system (see Figure 1, left).
ReferenceableGridCoverage: coverage whose domain consists of a referenceable grid – a grid associated with a transformation that can be used to convert grid coordinate values to values of coordinates referenced to a coordinate reference system (see Figure 1, right).
MultiTimeInstantCoverage: coverage providing a representation of the time instant/value pairs, i.e. time series (see Figure 2).
5.1.5.4.
Where possible, only these coverage types (or a subtype thereof) are used in INSPIRE application schemas.
16 It depends on the level of the “obligation” tagged value on the attribute, whether this is a
(Source: ISO 19136:2007) (Source: GML 3.3.0)
Figure 1 – Examples of a rectified grid (left) and a referenceable grid (right)
Figure 2 – Example of a MultiTimeSeriesCoverage (a time series)
−
Generally, in statistics rectified grids are used only as described in the INSPIRE theme Statistical Units (SU) [see DS - D2.8.III.1].
5.2 Application schema Population Distribution – Demography
5.2.1 Description
5.2.1.1. Narrative description
A statistical data distribution describes the structure of a "dissemination area" based on a set of measures of a phenomenon of interest. The notion of "population distribution" can be best understood with the following example. The picture represents the way the population is distributed within the surroundings of Bordeaux, here defined as a geographical rectangle. The surroundings of Bordeaux are our "area of Dissemination". This area is pictured with a set of red or white pixels which are actually small 200m wide grid cells.
For each cell population counts were produced: the "value" is just a number of people. The pixels are white when population is zero and darken when the population count gets higher. But the whole set of pixels - the whole set of grid cells - provide a complete picture of the area.
Figure 3: Example of population distribution
The aim of the proposed data model is to provide capabilities of exchanging the data that is behind such pictures. In this example: the whole set of figures that are associated to each pixel that are necessary to build the global picture that will represent the area of dissemination. The model is not restricted just to one form of area of dissemination, it is not restricted to grid cells as elementary components of the area of dissemination - statistical units described vectorial (census blocks, admin units) are also supported - and it is not restricted to simple population counts. The model is a generic one to allow almost any statistical data to be exchanged.
One part of the model is a kind of description of metadata that is not covered by the ISO 19115 / 9 metadata standards and that should be added as a header in the dataset.
An example: Attribute Value Domain "demography" Measure "populationAtResidencePlace" Classifications “sex” measurementUnit "person"
areaOfDissemination "surroundings of Bordeaux"
The domain describes the domain of statistical knowledge the value belongs to and the measure
contains the short term of the phenomenon which is counted. The classifications describe the type of classification used to calculate or aggregate the values. The area of Dissemination describes the area for which the statistical data are available and / or the area selected by the user.
Temporal dimension of population distribution is considered in the three aspects: the actual period of measurement and the theoretical reference period of the measurement and the period the data remain valid.
The second part of the model contains the elementary data values and the description by dimensions. Each value is characterised by a certain combination of thematical and a spatial dimensions. This part applies as often as values are available in the area disseminated / requested.
Attribute Value
Value <number> classificationItem "male"
geoReference <Statistical Unit>
NOTE: This example is simplified and does not represent all attributes of the model.
The Population distribution – demography data model is defined in a very generic way, and nearly any statistical value describing a statistical measured phenomenon e.g. human population, can be considered a part of it. Use cases show the need for statistical variables as population at residence place, population at work place and population density. These statistics need to be provided on a more detailed territorial level than what is possible to access already through the Eurostat databases, preferable on statistical units like grids or census districts.
The requirements reflect the role of this theme in the INSPIRE context. The National Statistical Institutes should not be forced to provide INSPIRE services for all statistics covering human population, as building two parallel systems (regional statistics already provided by Eurostat and regional statistics provided by the member states through INSPIRE) will both be costly and time consuming.
5.2.1.2. UML Overview
An overview of the Population distribution - demography package and referenced packages is provided in Figure 1 below. The Population Distribution - Demography package refers to the Base Types package for Identifier data type and some general base types to be used in accordance with the GCM. In addition the StatisticalUnit feature type of Annex III theme Statistical units is referenced to support the indirect positioning of statistical data with respect to the location on the Earth.
pkg PD
«applicationSchema» Core
+ StatisticalUnit (from Statistical Units)
«applicationSchema» Base Types + Identifier + SpatialDataSet + VoidReasonValue + ConditionOfFacilityValue + VerticalPositionValue
(from Base Types)
«applicationSchema»
Population distribution - demography + AgeBy5YearsValue + AgeByYearValue + AgeGroupValue + Classification + ClassificationItem + ClassificationItemTypeValue + ClassificationTypeValue + Dimensions + NACECodeValue + SexValue + SpecialValue + StatisticalDistribution + StatisticalValue + StatisticsMeasurementMethodValue + StatusValue + VariableValue
(from Population Distribution - Demography)
«import»
«import»
Figure 4: Package overview
The application schema for Population distribution - demography is shown in Figure 2 and described below.
The schema is structured with three types of classes: “StatisticalDistribution”, “StatisticalValue” and “StatisticalValue.Dimensions” and two groups of code lists.
class PD
Other code lists Code lists for classifications
From statisti cal units
«dataType»
Classification
+ type: Classificati onTypeValue
«dataT ype» ClassificationItem + type: ClassificationItemTypeValue «featureT ype» Core::StatisticalUnit «featureT ype» StatisticalDistribution + inspireId: Identifier [0..1] + areaOfDissemination: GM_Surface + universe: PT_FreeT ext [0..1] + domain: PT_FreeText + measure: VariableValue
+ measurementMethod: Stati sticsMeasurementMethodValue + measurementUnit: UnitOfMeasure + notCountedProportion: Number [0..1] + periodOfMeasurement: T M_Period + periodOfReference: T M_Period + periodOfValidity: TM_Period [0..1] + generalStatus: StatusValue «voidable, lifeCycleInfo» + beginLifeSpanVersion: DateT ime + endLi feSpanVersion: DateTime [0..1]
«dataT yp... Dimensions «dataType» StatisticalValue + value: Number [0..1] + specialValue: SpecialValue [0..1] + conventionallyLocatedProportion: Number [0..1] + approxi matelyLocatedPopulationProportion: Number [0..1] + comment: PT_FreeT ext [0..1]
+ flags: PT_FreeT ext [0..1] + status: StatusValue «voidable» + periodOfMeasurement: TM_Period [0..1] constraints {valueOrSpecialValue} «codeList» ClassificationTypeValue «codeList» ClassificationItemTypeValue «codeList» NACECodeValue «codeList» SexValue «codeList» AgeByYearValue «codeList» AgeBy5YearsValue Examples: ageGroup, ageBy5Years, ageByYear, sex, nace, etc.
Values: 0-5, 5-10, 10-15, 15-20, …, 95-100, 100. Values: 0-1, 1-2, 2-3, 3-4, 4-5, …, 99-100, 100. Val ues: femal e, male. Values: See http://ec.europa.eu/eur ostat/ramon/nomenclat ures/index.cfm? T argetUrl=LST_NOM_ DTL&StrNom=CL_NAC E2 «codeList» SpecialValue Examples: confidential, unknown, notAppli cable, etc.
«codeList»
StatisticsMeasurementMethodValue
Examples: count, relativeCount, percentage, median, average, etc.
«codeList»
StatusValue
Examples: definitive, final, preliminary, provi sional, semiDefinitive, etc. «codeList»
VariableValue
Examples: births, income, populationAtResidencePlace, populationAtWorkPlace, unemployedPopulation, employedPopulation, etc. «codeList» AgeGroupValue Values: 1-15, 15-65, 65+.
A reference toward a statistical unit may be done using either its INSPIRE i dentifier or another thematic identifier.
+dimensions 1 +values 1..* «version» +spati al 1 +thematic 0..* +classifi cations 0..* +items 1..* {classificationT ypeItemConsistency}
Feature Type: StatisticalDistribution
«dataType»
Classification
+ type: ClassificationTypeValue + type: ClassificationItemTypeValue «featureType» StatisticalDistribution + inspireId: Identifier [0..1] + areaOfDissemination: GM_Surface + universe: PT _FreeText [0..1] + domain: PT _FreeText + measure: VariableValue + measurementMethod: StatisticsMeasurementMethodValue + measurementUnit: UnitOfMeasure + notCountedProportion: Number [0..1] + periodOfMeasurement: T M_Period + periodOfReference: TM_Period + periodOfValidity: TM_Period [0..1] + generalStatus: StatusValue «voidable, lifeCycleInfo»
+ beginLifeSpanVersion: DateT ime + endLifeSpanVersion: DateT ime [0..1]
«dataT yp... Dimensions +dimensions +values 1..* +thematic 0..* +classifications 0..* +items 1..* {classificationT ypeItemConsistency}
Figure 6: Feature type StatisticalDistribution
The StatisticalDistribution is defined as a feature type for practical reasons, to be able to generate
the according GML. This type mainly acts as a header to keep general (meta-) information about the distribution and contains common properties of each component of the distribution.
To provide the INSPIREId is not mandatory. It may be useful for internal organisational reasons of the provider, if the query or result will be stored for use at a later time.
areaOfDissemination: The areas of dissemination is the part of the 2D world the
StatisticalDataDistribution describes, represented as a surface.
Figure 7: Statistical units, values and area of dissemination
The naming of the domains is not harmonised over Europe. Each provider should use the naming according his existing structure.
Example: List of domains from Eurostat’s database:
• Population and social conditions • Economy and finance
• Agriculture, forestry and fisheries • Industry, trade and services • External Trade
• Transport
• Environment and energy • Science and technology
The universe attribute provides information if the statistics cannot be assigned to domain and
measure. This is the case if statistics are produced for a certain use case on user request and must be documented here.
Example: “Agriculture employment” may be calculated by dividing the persons employed in agriculture by the number of total persons aged 18 to 64 in employment
The attribute measure contains the value of the code list variable, which describes in short- term the phenomena for which data provided.
The attributes measurementUnit and MeasurementMethod support description of the kind of measurements provided by the distribution. The possible values are taken from the corresponding code lists UnitOfMeasure and statisticsMeasurementMethod.
According the common approach in INSPIRE to describe the quality of the content of a dataset, some data quality considerations appear through the notCountedProportion attribute that reports the relative amount of population known to be in the area of interest but not delivered in any of its spatial elements.
According to Regulation 1205/2008/EC and because the time dimension is an important component of statistical information, the model includes three attributes to address this issue:
Recommendation 3 It is recommended that time attributes periodOfReference, periodOfValidity and periodOfMeasurement are provided.
periodOfReference
is the period when the data is supposed to give a picture of the area of interest..
In PD the reference period can be a period or a fixed date. In the last case one should use the same date for the beginning and the end.
periodOfValidity
In SU and PD the Validity is the period in which data remain relevant. For PD in most cases this is forever. In that case the 2nd date is left empty.
periodOfMeasurement
This attribute is only useful in PD. The date / period the observation has been taken, the data was collected.
NUTS units Census variables in Poland periodOfReference 1.1.2006 - 1.1.2006 31.3.2011 – 31.3.2011 periodOfValidity 1.1.2008 - 31.12.2011 1.1.2012 - open
PeriodOfMeasurement - - 1.4.2011 - 30.6.2011
To facilitate a user driven selection of data sets / values for a differential update the attributes
beginLifeSpanVersion and endLifeSpanVersion are provided. These attributes are used by a user
who is searching regularly but expecting only those values which are changed since his last query, not all data values. (What has changed since my last enquiry?)
The attribute generalStatus is used to describe the status of the values for the complete dataset, like definitive, semi-definitive or provisional and preliminary or final (Examples from Eurostat publications).
The classification attribute can be used to represent a set of distributions with respect to the way of
splitting the statistical values into different groups using one or several classifications of the individuals according to their characteristics. No classification may happen for the “Total” values.
The {ClassificationItemTypeConsistency} rule defines that all ClassificationItemTypes used to classify the value should be included into this list.
Example:
statisticalDistribution.classification statisticalValue.
(1) sex dimensions.
(2) ageBy5years classificationItem(1) classificationItem(2) Value
female 0-5 134 male 0-5 141 female 5-10 128 male 5-10 111 female 10-15 89 : : :
Data Type: StatisticalValue class PD «dataType» StatisticalValue + value: Number [0..1] + specialValue: SpecialValue [0..1] + conventionallyLocatedProportion: Number [0..1] + approximatelyLocatedPopulationProportion: Number [0..1] + comment: PT_FreeText [0..1] + flags: PT_FreeText [0..1] + status: StatusValue «voidable» + periodOfMeasurement: TM_Period [0..1] constraints {valueOrSpecialValue}
Figure 8: Data type StatisticalValue
The data type StatisticalValue supports the description of the individual values of the distributions: This description contains the reference to understand to which spatial element and to which classification items the value refers to. The elementary datum can be seen as something that can be located in an n-dimensional space comprising the classical two dimensional one, but also the dimensions relative to the classifications used. For example, a simple population count on each municipality or on one country will only need a reference to the two dimensional space viewed through the municipalities or country list. But the same population divided by sex will need an additional third dimension.
In the centre of this item is the value attribute, which contains the number statistically calculated. In case the value cannot be provided (e.g. privacy, error, confidentiality) the reason for value absence should be expressed using the specialValue attribute. It is required that either a value or a special value is provided.
Values can be accompanied with flags and footnotes (comment attribute) as usual in the statistics community, giving any kind of information useful to describe particular situations.
Two additional attributes related to data quality gives hints about the accuracy of the measure:
conventionallyLocatedProportion and approximatelyLocatedProportion. They are discussed in
the quality section.
The attribute status is used for exceptions of a certain value to what was specified in the generalStatus information of the statisticalDistribution.
Because there is no harmonised concept how to use the correct codes of the attributes “specialValue” and “flags”, the corresponding code list must be provided by the data provider. It is recommended to the statistical community to develop a harmonised concept of using special values, flags and status.
Additionally, for each StatisticalValue a time stamp (periodOfMeasurement) can be provided, to allow exceptions to what was specified in the general information.
From statistical units «dataType» ClassificationItem + type: ClassificationItemTypeValue «featureType» Core::StatisticalUnit «dataTyp... Dimensions
A reference toward a statistical unit may be done using either its INSPIRE identifier or another thematic identifier.
+dimensions 1 «version» +spatial 1 +thematic 0..* +items 1..* {classificationTypeItemConsistency}
Figure 9: Data type StatisticalValue.Dimensions
NOTE: The association between Dimensions and the Core::StatisticalUnit will be established using the attribute “thematicallyID” instead of the “INSPIREID” (see below: Referencing data to statistical units”).
According to the SDMX view on dimensions, all dimensions of the value (thematical and spatial) are summarized in a unique data type dimensions.
Note: The cardinality of the attribute dimensions is 1, because at least the geographical reference has to be provided.
In case an additional splitting / grouping of the statistical values are needed according to one or more classifications, the attribute classificationItem will be used.
Example: To describe a value representing residential population by sex, nationality and 5 year age classes three thematical classificationItems are used “male”, “French”, and “25-30”, out of the domains of the code lists “Sex”, “Nationality” and “age5Years”.
Referencing data to statistical units:
All statistical data are spatially referenced (indirectly linked to a statistical unit), which is expressed by an common identifier, in SDMX called geographical dimension. In the geographical word (in GIS) these identifiers are used to identify the corresponding geometry and to join the tabulated data. These ID build the bridge (link) between the statistical and geographical world. Difficulties rise because different rules are used, when and how these identifiers have to change during an evolution.
A strong general requirement of the GCM in INSPIRE is, that an ID should be capable of uniquely and permanently identifying that with which it is associated [ISO 19135]. This is a rule which do not apply for geo-attributes (identifiers) used in the statistical community.
Therefore beside the INSPIRE ID an additional thematical identifier attribute is provided in the VectorStatisticalUnit feature type. Only this thematical ID has to be used for linking PD and SU data.
IR Requirement 4 For linking thematical statistical data with SU a thematical identifier shall be used separate from the INSPIRE ID.
In the case that the update rules for the identifier of a certain statistical unit follow the rules of the GCM resp. ISO [ISO 19135] without any exceptions, the INSPIRE identifier can be copied as thematical identifier.
Because the spatial object to which a thematical ID is linked (e.g. a municipality) can change without changing the thematical ID, some version information is requested. Typically and easy to use this is the reference year. This is necessary to avoid linking statistical with geometrical data of different reference years.
